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1 Scope 

The present document describes the Procedures on the Functional Entities and Call Flows for the protocols and their 
possible enhancements to support IPTV services based on the architecture and stage 2 information flows described in 
TS 182 027 [2]. 

The possible enhancements of protocols will define the scope of new or enhanced protocol specifications. 

Besides, the interaction with other Simulation Service will be considered. 

NOTE: The present document relies on the architectural framework defined in TS 182 027 [2] for IMS-based 
IPTV Stage 2 and may need to be updated once the open issues identified in the present document are 
resolved. 

The present document is applicable to: 

• the interface between the User Equipment (UE) and the Call Session Control Function (CSCF); 

• the interface between the S-CSCF and IPTV Service Control Functions (SCF); 

• the interface between the S-CSCF and IPTV Service Discovery Functions (SDF); 

• the interface between the S-CSCF and the Media Control Functions (MCF); 

• the interface between the User Equipment (UE) and IPTV Service Selection Functions(SSF); 

• the interface between the User Equipment (UE) and Elementary Control Functions (ECF)/Elementary 
Forwarding Functions (EFF); 

• the interface between the User Equipment (UE) and IPTV Service Control Functions (SCF). 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vahd at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[2] ETSI TS 182 027: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS 
subsystem". 

[3] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[4] ETSI TS 102 47 1 : "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic 

Service Guide (ESG)". 
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[5] ETSI TS 102 472: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content 

Delivery Protocols". 

[6] OMA-TS-BCAST-ServiceGuide-Vl-0: "Open Mobile Alliance: Service Guide for Mobile 

Broadcast Services". 

[7] OMA-TS-BCAST-DVB-Adaptation-Vl-0: "Open Mobile Alliance: Broadcast Distribution System 

Adaptation - IPDC over DVB-H". 

[8] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)" . 

[9] IETF RFC 4825: "The Extensible Markup Language (XML) Configuration Access Protocol 

(XCAP)". 

[10] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Security; Security Architecture". 

[11] ETSI TS 124 109: "Universal Mobile Telecommunications System (UMTS); Bootstrapping 

interface (Ub) and network application function interface (Ua); Protocol details (3GPP TS 24.109 
Release 7)". 

[12] ETSI TS 183 023: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Extensible Markup Language 
(XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating NGN 
PSTN/ISDN Simulation Services". 

[13] ETSI TS 102 539: "Digital Video Broadcasting (DVB); Carriage of Broadband Content Guide 

(BCG) information over Internet Protocol (IP)". 

[14] ETSI TS 133 222: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Generic Authentication Architecture (GAA); Access to 
network apphcation functions using Hypertext Transfer Protocol over Transport Layer Security 
(HTTPS) (3GPP TS 33.222 Release 7)". 

[15] IETF RFC 5874: "An Extensible Markup Language (XML) Document Format for Indicating A 

Change in XML Configuration Access Protocol (XCAP) Resources". 

[16] ETSI TS 184 009: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN) Rules covering the use of TV URIs for the Identification of 
Television Channels". 

[17] IETF RFC 3925 : "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol 

version 4 (DHCPv4)". 

[18] IETF RFC 1035: "Domain names - implementation and specification". 

[19] IETF RFC 1034: "Domain names - concepts and facilities". 

[20] ETSI ES 283 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
[Release 7], modified]". 

[21] ETSI ES 283 030: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Presence Service Capability; Protocol Specification 
[3GPP TS 24.141 V7.0.0, modified and OMA-TS-Presence-SIMPLE-Vl-0, modified]". 

[22] Void. 

[23] OMA-TS-Presence-SIMPLE-Vl-O-20060725-A: "Open Mobile AlUance: Presence SIMPLE 

Specification". 

[24] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Internet Protocol (IP) multimedia call control protocol 
based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 
(3GPP TS 24.229 Release 9)". 
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IETF RFC 5956: "Forward Error Correction Grouping Semantics in Session Description 
Protocol". 

IETF RFC 5 875: "An Extensible Markup Language (XML) Configuration Access Protocol 
(XCAP) Diff Event Package". 

Void. 

IETF RFC 3376: "Internet Group Management Protocol, Version 3". 

IETF RFC 3810: "Multicast Listener Discovery Version 2 (MLDv2) for IPv6". 

IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

IETF RFC 2782: "A DNS RR for specifying the location of services (DNS SRV)". 

IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2". 

ETSI TS 102 822-3-1: "Broadcast and On-line Services: Search, select, and rightful use of content 
on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 1: Phase 1 - Metadata 

schemas". 

ETSI TS 101 154: "Digital Video Broadcasting (DVB); Specification for the use of Video and 
Audio Coding in Broadcasting Apphcations based on the MPEG-2 Transport Stream". 

ETSI TS 102 822-4: "Broadcast and On-line Services: Search, select, and rightful use of content 
on personal storage systems ("TV-Anytime"); Part 4: Phase 1 - Content referencing". 

ETSI ES 283 035: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e2 interface based 
on the DIAMETER protocol". 

DSL Forum TR-069 Amendment 2: "CPE WAN Management Protocol". 

ETSI TS 183 060: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); Resource and Admission Control Subsystem (RACS); 
Re interface based on the DIAMETER protocol". 

W3C: "Synchronized Multimedia Integration Language (SMIL 2.1)". 

IETF RFC 4660: "Functional Description of Event Notification Filtering". 

IETF RFC 4661: "An Extensible Markup Language (XML)-Based Format for Event Notification 
Filtering". 

IETF RFC 4235: "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol 
(SIP)". 

IETF RFC 5760: "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions 
with Unicast Feedback". 

IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Apphcations". 

IETF RFC 3611: "RTP Control Protocol Extended Reports (RTCP XR)". 

IETF RFC 5576: "Source-Specific Media Attiibutes in the Session Description Protocol (SDP)". 

IETF RFC 3605: "Real Time Control Protocol (RTCP) attribute in Session Description Protocol 
(SDP)". 

ETSI TS 102 822-6-1: "Broadcast and On-line Services: Search, select, and rightful use of content 
on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a bi-directional 
network; Sub-part 1: Service and transport". 

ETSI TS 126 234: "Technical Specification Group Services and System Aspects; Transparent 
end-to-end Packet- switched Streaming Service(PSS); Protocol and codecs (3GPP TS 26.234 
Release 9)". 
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[50] OMA-TS-SIMPLE-IM-V1-0-20100322-C:"OMA: Instant Messaging using SIMPLE". 

[51] ETSI TS 126 237: "IP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and 

Multimedia Broadcast/Multicast Service (MBMS) User Service; Protocols"; (3GPP TS 26.237 
Release 9)". 

[52] IETF RFC 4745: "Common Policy: A Document Format for Expressing Privacy Preferences". 

[53] IETF RFC 5025: "Presence Authorization Rules". 

[54] OMA-TS-Presence-SIMPLE-XDM: "Presence XDM Specification". 

[55] ETSI TS 102 822-3-3: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 3: Phase 2 - Extended 
Metadata schema". 

[56] IETF RFC 5905: "Network Time Protocol Version 4: Protocol and Algorithms Specification". 

[57] IETF RFC 355 1 : "RTP Profile for Audio and Video Conferences with Minimal Control". 

[58] ETSI TS 124 237: "Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia 

(IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuity; Stage 3 
(3GPP TS 24.237 Release 9)". 

[59] IETF RFC 5627: " Obtaining and Using Globally Routable User Agent URIs (GRUU) in the 

Session Initiation Protocol (SIP)". 

[60] ETSI TS 181 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN Services and 
IPTV". 

[6 1 ] IETF RFC 5234: "Augmented BNF for Syntax Specifications: ABNF" . 

[62] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[63] IETF draft-ietf-sipping-config-framework-18: " A Framework for Session Initiation Protocol User 

Agent Profile Delivery". 

NOTE: Available at draft-ietf-sipping-config-framework- 18 . 



[64] 


IETF 


RFC 


5626 


[65] 


IETF 


RFC 


4122 


[66] 


IETF 


RFC 


4395 


[67] 


IETF 


RFC 


3406 


[68] 


IETF 


RFC 


2327 


[69] 


IETF 


RFC 


3265 


[70] 


IETF 


RFC 


3891 



2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] Void. 

[i.2] ETSI TS 183 017: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER protocol for 
session based policy set-up information exchange between the Application Function (AF) and the 
Service Policy Decision Function (SPDF); Protocol specification". 



ETSI 



20 



ETSI TS 183 063 V3.5.1 (2011-02) 



[i.3] ETSI TS 183 033: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia; Diameter based protocol for the interfaces 
between the Call Session Control Function and the User Profile Server Function/Subscription 
Locator Function; Signalling flows and protocol details [3GPP TS 29.228 and 3GPP TS 29.229, 
Release 9]". 

[i.4] ETSI TS 129 329: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Sh interface based on the Diameter protocol; Protocol 
details (3GPP TS 29.329 Release 7)". 

[i.5] IEEE 1003.1-2004: "Standard for information technology - portable operating system interface 

(POSIX). Shell and utilities". 

[i.6] F. Boronat, J. Lloret, M. Garcia, "Multimedia group and inter-stream synchronization techniques: 

A comparative study", Elsevier Information Systems 34 (2009), pp. 108-131. 

[i.7] ETSI TR 187 013: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Feasibility study on IPTV Security Architecture". 

[i.8] ITU-T Recommendation G.l 14: "General Recommendations on the transmission quality for an 

entire international telephone connection. One-way transmission time". May 2003. 

[i.9] IETF draft: "RTSP 2.0 Asynchronous Notification, draft-stiemerling-rtsp-announce-Ol". 

[i.lO] IETF draft-stiemerling-rtsp-announce-01: "RTSP 2.0 Asynchronous Notification". 

[i.l 1] IETF draft-ietf-sip-ipv6-abnf-fix-05: "Essential correction for IPv6 ABNF and URI comparison in 

RFC 3261". 

[i.l2] lANA: "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry". 

NOTE: http://www.iana.org/assignments/rtcp-xr-block-tvpes/rtcp-xr-block-tvpes.xhtml . 

[i. 1 3] lANA: "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) 

Parameters Registry". 

NOTE: http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-parameters.xhtml . 

[i.l4] ETSI TS 182 028: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN integrated IPTV subsystem Architecture". 

[i. 15] draft-ietf-sipcore-info-events-08. 

[i. 16] IETF RFC 3725: "Best CuiTent Practices for Third Party Call Control (3pcc) in the Session 

Initiation Protocol (SIP)". 



3 Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ABNF 


Augmented BNF(Backus-Naur Form) 


ACK 


ACKnowledge character 


AP 


Authentication Proxy 


AS 


Application Server 


AUID 


Application Unique ID 


B2BUA 


Back To Back UA 


BC 


Broadcast 


BCG 


Broadband Content Guide 


CCR 


Credit-Control Request 


CNGCF 


Customer Network Gateway Configuration Function 


CoD 


Content on Demand 


C-PVR 


Client-side Personal Video Recorder 


CRS 


Content Recommendation Service 
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CSCF 


Call Session Control Function 


DHCP 


Dynamic Host Configuration Protocol 


DNS 


Domain Name System 


DVB 


Digital Video Broadcasting 


DVBSTP 


DVB SD&S Transport Protocol 


ECF/EFF 


Elementary Control Function/Elementary Forwarding Function 


EPG 


Electronic Program Guide 


ERE 


Extended Regular Expressions 


ESG 


Electronic Service Guide 


EEC 


Forward Error Correction 


GRUU 


Globally Routable User Agent URIs 


HTTP 


Hypertext Transfer Protocol 


lARI 


IMS Application Reference Identifier 


I-CSCF 


Interrogation - Call Session Control Function 


ICSI 


IMS Communication Service Identities 


ID 


Identifier 


IFC 


Initial Filter Criteria 


IGMP 


Internet Group Management Protocol 


IMS 


IP Multimedia Subsystem 


IP 


Internet Protocol 


IPTV 


Internet Protocol Television 


MCE 


Media Control Function 


MDE 


Media Delivery Function 


ME 


Media Function 


MLD 


Multicast Listener Discovery 


MSAS 


Media Synchronization Application Server 


NGN 


Next Generation Network 


NPT 


Normal Play Time 


N-PVR 


Network-side Personal Video Recorder 


NTP 


Network Time Protocol 


OMA 


Open Mobile Alliance 


P-CSCE 


Proxy - Call Session Control Function 


PPV 


Pay Per View 


PSC 


Personalised Service Composition 


PSI 


Public Service Identity 


RACS 


Resource and Admission Control Subsystem 


RTCP 


Real Time Control Protocol 


RTP 


Real Time Protocol 


RTSP 


Real Time Streaming Protocol 


SAD 


Service Action Data 


SAH 


Service Access History 


SC 


Synchronization Client 


SCE 


Service Control Function 


S-CSCE 


Serving - Call Session Control Function 


SD 


Standard Definition 


SD&S 


Service Discovery and Selection 


SDE 


Service Discovery Function 


SDP 


Session Description Protocol 


SGDD 


Service Guide Delivery Descriptors 


SGDU 


Service Guide DeUvery Units 


SIP 


Session Initiation Protocol 


SNTP 


Simple Network Time Protocol 


SOAP 


Simple Object Access Protocol 


SRV 


Service Records 


SSD 


Service State Data 


SSE 


Service Selection Function 


SSRC 


Synchronization source 


TCP 


Transmission Control Protocol 


TLS 


Transport Layer Security 


TsTV 


Time shift TV 


UA 


User Agent 


UDP 


User Datagram Protocol 
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UE 

UGC 

UPSF 

URI 

XCAP 



User Equipment 

User Generated Content 

User Profile Server Function 

Uniform Resource Identifier 

XML Configuration Access Protocol 



XDMSXML (extensible markup language) Data Management Server 
XML extensible Markup Language 



Applicability 



4.1 Overview 

The overall functional architecture for the IMS-based IPTV service conforms to TS 182 027 [2]. 
This clause provides the hst of protocols and related reference points. 




Figure 4.1 : Protocols used in functional architecture for the llUIS-based IPTV service 
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Table 4.1 : IMS based IPTV functional entities and protocols used on reference points 



FE/ 
Reference 

point 
(protocol) 


UE 


IMS core 


UPSF 


SDF 


SSF 


SCF 


MCF 


MDF 


ECF/ 
EFF 


UE 


— 


Gm 
(SIP/SDP) 


— 


via Core 

IMS 
(SIP/SDP) 


Xa 
(HTTP, 
DVBSTP, 
FLUTE) 


Ut 
(HTTP), 
via Core 

IMS 
(SIP/SDP) 


Xc 
(RTSP) 
(Note 1) 


Xd 

(UDP/RTP 
/RTCP/ 
HTTP) 
(Note 1 ) 


Dj, Di 
IGMP/ 
MLD 


IMS core 


Gm 
(SIP/SDP) 




Cx 
(Diameter) 


ISC 
(SIP/SDP) 




ISC 
(SIP/SDP) 


y2 

(SIP/SDP) 






UPSF 




Cx 
(Diameter) 




Sin 
(Diameter) 


— 


Sh 

(Diameter) 




— 


— 


SDF 


via Core 

IMS 
(SIP/SDP) 


ISC 
(SIP/SDP) 


Sh 
(Diameter) 














SSF 


Xa 
(HTTP, 
DVBSTP, 
FLUTE) 


— 


— 


— 


— 


Ss' 
(not 
defined) 


— 


— 


— 


SCF 


Ut 
(HTTP), 
via Core 

IMS 
(SIP/SDP) 


ISC 
(SIP/SDP) 


Sh 
(Diameter) 


— 


Ss' 
(not 
defined) 




via Core 
IMS and 
y2 

(SIP/SDP) 


— 


— 


MCF 


Xc 
(RTSP) 
(Note 1) 


y2 

(SIP/SDP) 








via Core 
IMS and y2 
(SIP/SDP) 




Xp 
(not 
defined) 




MDF 


Xd 

(UDP/RTP/ 
RTCP/HTT 

P) 
(Note 1) 












Xp 
(not 
defined) 
























ECF/ EFF 


Dj, Di 
IGMP/ MLD 


















NOTE 1 : As described in TS 182 027 [2], clauses 6.4 and 6.5, Xc and Xd are logical reference points that can be 
decomposed into Dj and possibly Di, Ds or Iz reference points depending on the location of the MCF or 
MDF, and the HTTP is used for the content download. 

NOTE 2: Annex H lists compliance requirements for the protocols listed in this table. 



Usage of the SIP/SDP protocol across the following interfaces is described in clause 5: 
interface Gm; 
interface ISC; 
interface y2. 

Usage of the HTTP protocol across the following interfaces is described in clause 6: 
interface Xa; 

interface Ut; 
interface Xd. 

Usage of the RTSP protocol across the following interfaces is described in clause 7: 

interface Xc; 

interface Di, Dj, Ds or Iz. 
Usage of the UDP/RTP/RTCP protocol across the following interfaces is described in clause 11: 

interface Xd; 

interface Di, Dj, Ds or Iz. 
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Usage of the IGMP/MLD protocol across the following interfaces is described in clause 8: 
interface Xd; 
interface Dj, Di, Ds or Iz. 

NOTE: Whether usage of multicast protocols (IGMP.MLD) is supported on Xc, Xd interface or how MDF joins 
multicast streams (e.g. for N-PVR or BC with trick mode services) is out of the scope of the present 
document. 

Usage of the DVB ST? protocol across the following interface is described in clause 9: 
interface Xa. 

Usage of the FLUTE protocol across the following interface is described in clause 10: 
interface Xa. 

4.2 Functional entities 

4.2.1 User Equipment (UE) 

The UE is a functional entity that provides the user with access to IPTV services. For time -and synchronization- 
sensitive services, the UE shall support NTP/SNTP-based network time services as described in clause 8.2 of [3]. 

4.2.2 Service Control Function (SCF) 

The SCF is a functional entity that provides IPTV service logic and the functions required to support execution of such 
logic. 

4.2.3 Service Discovery Function (SDF) 

An SDF is a functional entity that provides service attachment information to the UE. 

4.2.4 Service Selection Function (SSF) 

An SSF is a functional entity that provides service selection information to the UE. 

4.2.5 Media Control Function (MCF) 

The MCF is a functional entity that provides the UE with functions required to control media flows and manages the 
MDFs under its control. 

4.2.6 Media Delivery Function (MDF) 

The MDF is a functional entity that delivers content data to the UE. 

4.2.7 Core-IMS 

The Core IMS includes a number of functional entities identified in ES 282 007 [1]. For the purpose of supporting IF*TV 
services, the following functional entities of the Core IMS are involved: 

the P-CSCF; 

the S-CSCF; 

the I-CSCF; 
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the IBCF in case the P-CSCF and the I/S-CSCF or the CSCF and the MCF are in different administrative 

domains. 

The behaviour of these functional entities with regards to SIP and SDP shall conform to ES 283 003 [20]. 

4.2.8 Inter-destination media synciironization entities 

Figure 4.2. shows the two functional entities involved in inter-destination media synchronization, i.e. the media 
synchronization application server (MSAS) and Synchronization Client (SC). Optionally, there is also a Synchronization 
Client' (SC). These functional entities are described in clauses 4.2.8.1, 4.2.8.2 and 4.2.8.3, respectively. 

Figure 4.2: Functional entities and reference points for inter-destination media synchronization 

As described in TS 182 027 |2|, there exist different mappings of the SC and MSAS onto the functional entities 
depicted in figure 4. 1 . The mapping of the SC as an elementary function of the UE is aimed at small-scale deployments 
of services that require media synchronization and only a hmited number of UEs that use media synchronization. It 
reuses existing IPTV sessions. 

NOTE: Synchronization signalling procedures are initiated by the SC. This means that a UE without SC 
functionaUty will not be involved in synchronization signalling. 

The mapping of the SC as an adjunct function that may be co-resident with any of the appropriate elements of the 
Transport Processing Function is aimed at large-scale deployment of media synchronization. 

The process of inter-destination media synchronization involves three basis steps: 

1) Synchronization session initiation 

2) Synchronization status information and synchronization settings instruction exchange 

3) Synchronization session termination 

Given these steps, the Sync reference point is decomposed as follows: 

• Synchronization session initiation information is exchanged over the Gm and ISC reference points, using 
SIP/SDP. Synchronization session initiation information can also be exchanged over the Xc reference point, 
using RTSP/SDP. 

• Synchronization status information and delay information in the form of synchronization settings instruction is 
exchanged over the Xd reference points, using RTCP. 

• Synchronization session termination is exchanged over the Gm and ISC reference points, using SIP/SDP. 
Synchronization session termination information can also be exchanged over the Xc reference point, using 
RTSP/SDP. 

RTCP reports with synchronization status information or synchronization settings instructions can be sent directly 
between UEs, if a direct communication channel between UEs already exists. In that case, one UE acts as co-located 
SCh-MSAS as described in clauses 1 1.3.2 and A.5.2.3. 

The Sync' reference point is used to report synchronization correlation information on the synchronicity relationship 
between the incoming media stream (which could be received by some SCs)and the outgoing media stream(s) (which 
could be received by other SCs) from the SC to the MSAS. The Sync' reference point uses RTCP. 
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4.2.8.1 MSAS 

The MSAS is a functional entity that coordinates session synchronization with SCs and SC for inter-destination media 
synchronization purposes. The MSAS session-level capabiUties are reflected as independent functional entity or as 
elementary functions of the SCF, its media-level capabilities are reflected as adjunct functions of other functional 
entities. For synchronization using a direct communication channel between multiple UEs, the MSAS is co-located with 
the SC in a UE. Tasks of the MSAS are setting up and accepting synchronization sessions with/from SCs; collecting 
synchronization status information from SCs; collecting synchronization correlation information from SCs; calculating 
delay information and derive synchronization settings instructions for the SCs and distributing synchronization settings 
instructions to SCs. 



4.2.8.2 SC 

The SC is a functional entity that coordinates session synchronization with the MSAS for inter-destination media 
synchronization purposes. It is an elementary function of the UE or an adjunct function of the Transport Processing 
Functions. Tasks of the SC are setting up and accepting synchronization sessions with/from the MSAS; sending 
synchronization status information to the MSAS; receiving delay information in the form of synchronization settings 
instructions from the MSAS; and delaying (buffering) a media stream according to the received synchronization settings 
instruction. 



4.2.8.3 SC 

The SC is a functional entity that assists session synchronization by the MSAS for inter-destination media 
synchronization purposes. It is an elementary or adjunct function of functional entities that modify and/or re-originate 
media streams, e.g. a transcoder or a mixer in an MDF. 



4.2.9 Service Protection and Content Protection function (SCP) 

In the IMS based IPTV architecture, the functional entities and elementary functions that are responsible for Service 
protection and content protection are defined in TS 182 027 [2] clause 10.2 and 10.3, the NGN security architecture 
TS 187 003 [10], and the IPTV security architecture TR 187 013 [i.7]. 
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4.3 Compliance 

Compliance for the IMS-based IPTV service conforms to table 4.2. 

Table 4.2: IPTV services and features supported by TISPAN IMS based IPTV subsystem 



NGN IPTV 


TiSPAN R3 


TiSPAN R3 


Service & Feature 


Stage 2 


Stage 3 


Specification 


TS 182 028 [1.14] 
Release 3 


Present 
document 


Linear/ Broadcast TV 


M 


M 


Linear/ Broadcast TV with Trick Play 








Time Shifted TV 








Content on Demand (CoD) 


M 


M 


Push CoD 








Networl< PVR 


M/0 


M/0 




(See note 2) 


(See note 2) 


Client PVR 










(See note 2) 


(See note 2) 


Audio 








Pay-Per-View 








Interactive TV 








Service discovery 


M 


M 


Service Information (EPG) 


M 


M 


Parental Control 


M/0 


M/0 




(See note 3) 


(See note 3) 


User Profiling & Personalization 








Communications and Messaging 








Notifications 








IPTV Presence 








Interaction between users 








Interaction with NGN services 








Advertising 


M 


M 




^Spp nntp 4^ 


^Spp nntp 4^ 


Targeted Advertising 








User Generated Content 








Internationalization 








Content recommendation 








Games 








Picture 








Bookmarks 








Personalized channel 








Personalized Service Composition 








Service Portability 








Service Continuation between IPTV 








UEs 






Service Continuation fixed-mobile 








Remote Control of IPTV services 








Emergency Information. 








Interaction with 3™ Party application 
(e.g. Parlay) 








Service synchronization 








Incoming call management 








NOTE 1 : M - IVIandatory, 0- Optional, NA - not available or not specified 

(out of scope in release) in architecture. 
NOTE 2: It is recommended that at least one type of PVR is supported 


by the IPTV system. 
NOTE 3: Mandating this feature is subject to local regulatory policies. 
NOTE 4: Advertising refers to traditional broadcast based advertising 


services which impose no new requirements on IMS based 
IPTV subsystem. 



Features that are only used by optional services are optional as well. 
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5 Procedures using SIP/SDP for IMS-based IPTV 

Use the SIP/SDP protocol across the following interfaces is described in this clause: 

• interface Gm; 

• interface ISC; 

• interface y2. 

SIP/SDP capable functional entities are following: 

• UE. 

• SCF. 

• SDF. 

• MCF. 

• Core IMS. 

NOTE: Summary of compliancy requirements and referred specification are listed in clause H. 1 . 

5.1 User Equipment (UE) 

5.1 .1 Procedure for IMS registration 

As specified in TS 182 027 [2J, clause 8.2 the UE shall perform IMS registration before launching a service attachment 
procedure. 

The behaviour of the UE with regards to IMS registration shall comply with ES 283 003 [20]. 

5.1 .2 Procedure for service attacliment 

If the SDF is known as per annex I the Pull mode as in clause 5.1.2.2 shall be used, else the UE shall be preconfigured 
to use the pubhc user identity of the user to send a SIP SUBSCRIBE request according to the Pull mode or to expect a 
SIP MESSAGE request according to Push mode as in clause 5.1.2.1. 

5.1.2.1 Push mode 

Upon receipt of a SIP MESSAGE request from the SDF, the UE shall parse the XML document as described in 
clause 5.1.2.2.2. 

5.1.2.2 Pull mode 

Service Attachment, the UE shall generate a SUBSCRIBE request. The behaviour of the UE when processing a 
SUBSCRIBE request shall conform to ES 283 003 [20], clause 5.1.2A.1. 



ETSI 



29 



ETSI TS 183 063 V3.5.1 (2011-02) 



5.1.2.2.1 Subscription 

When the UE intends to retrieve service attachment information from the SDF, it shall generate a SUBSCRIBE request 
for the "ua-profile" event package defined in annex Y. 

The contents of the SUBSCRIBE request shall be as follows: 

• The value of the Request-URI shall be set to one of following: 

The PSI of the SDF which is retrieved using SDF Discovery procedures specified in annex I, or 
When the SDF identify is not present the public user identity of the IPTV end user. 

• The From and To header shall be set to the public user identity of the IPTV end user. 

• The Accept header shall include the content-type identifier that corresponds to the registered MIME type of 
XML documents representing IPTV profiles: "application/vnd.etsi.iptvdiscovery+xml". 

• The Event header shall be set to the "ua-profile" event package. 

• The Event parameters shall be set as follows: 

The "profile-type" parameter shall be set to "application". 

The "vendor", "model" and "version" parameter values shall be set to values specified by the 
implementer of the user equipment, as specified in ES 283 003 [20]. 

The "appids" parameter shall be set to "urn:org:etsi:ngn:applications:ims-iptv-service-discovery". 
The UE may include a SIP SUBSCRIBE message body associated with the appid 

" urn:org:etsi:ngn:applications:ims-iptv-service-discovery ". The message body includes the capabilities of the UE 
which is sent to the SDF. 

NOTE: Process of registering the appid is aligned with IETF specification in annex Y. 

If the SIP SUBSCRIBE contains a message body, the details of the SIP SUBSCRIBE are as follows: 

• Content Type header shall be set to "application/vnd.etsi.iptvueprofile-nxml". 

• A message body shall be present for conveying UE-specific information as defined in annex P. This includes: 

User Equipment ID. 

User Equipment Class: Specifies the type of UE. The currently defined types are "STB", "Mobile" and 
"PC". 

UE Capabilities: This defines the set of UE capabilities and could include: 

■ Physical resolution of the screen of the rendering device (defined in vertical and horizontal number 
of pixels). 

■ Supported coding formats (defined using the Coding XML element from TV- Anytime 
(TS 102 822-3-1 [33]), and using the classification schemes from MPEG7 and DVB). 

■ Optionally, supported Video Frame Rates (defined as per TS 101 154 [34]) associated with the 
encoding format. 

■ If the UE supports a content protection, it shall include in its UE capabilities, supported Content 
Protection System associated with the supported protected formats. A Content Protection System is 
defined via a URN with the DVB CA System ID (16 bit number) as registered in DVB 
http://www.dvbservices.com/identifiers/ca system id ). It shall be signalled by prefixing the 
decimal number format of CA_System_ID with "urn:dvb:casystemid:". For example, the 
CA_System_ID hexadecimal 0x1234, is encoded as "urn:dvb:casystemid:4660". Note that the 
decimal number format of CA_System_ID shall not have leading zeroes. A supported protected 
format shall be signalled by its mime type (i.e. "video/mp2t" for MPEG2-TS). 

Supported transport protocols (MPEG2TS over UDP, MPEG2TS over RTP, direct RTP). 
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Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. 

The UE shall automatically refresh the subscription, either 600 seconds before the expiration time if the initial 
subscription was for greater than 1 200 seconds, or when half of the time has expired if the initial subscription was for 
1 200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall 
still consider the original subscription valid for the duration of the most recently known "Expires" value according to 
ES 283 003 [20]. Otherwise, the UE shall consider the subscription invalid and start a new initial subscription according 
toES 283 003 [20]. 

5.1.2.2.2 Receiving notifications 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription, the UE shall look for a 
message body with a content-type header indicating "application/vnd.etsi.iptvdiscovery-nxml ". The IPTV application 
within the UE shall parse the XML document contained in the message body. 

The list of parameters which are described in clause 5.2.2.3 shall be used for service selection information retrieval 
according to clause 6.1.1 in unicast mode and clause 8.1.1 in multicast mode. 

When parsing the list of parameters the UE shall take the following action: 

• Information relates to SSF whom the UE has already an entree. 

If the " ©version" attribute is present and has not the same value or if not present, then the UE performs 
the following actions: 

■ For parameters related to this SSF already present in the UE: the UE shall update these parameters 
with the new values sent by the SSF. If the Segment® Version has not the same value, the UE shall 
update service selection information from the SSF before using it. 

■ For parameters related to this SSF not present in the UE: the UE shall store the new parameters. 

If the " ©version" attribute is present and has the same value, the UE shall not update the stored SSF 
information. 

• Information relates to an SSF not known by the UE: the UE creates a new entry for this SSF with all indicated 
parameters. 

After all elements have been processed, the UE shall return a SIP 200 OK response to the NOTIFY request. 

Failure to perform subscription refresh does not imply that there is a loss of communication to SSF or SCF. The UE has 
an option to continue using the lists of parameters from the last NOTIFY. 

After deregistration, the UE may keep stored information on per user basis. As for subscription refresh, the UE may use 
the stored information if initial subscription fails after a new registration. 

5.1 .3 Procedure for BC service 
5.1 .3.1 UE-initiated session initiation 

The UE shall support the procedures specified in ES 283 003 [20] for originating sessions. 

Upon a request for a BC session initiation, the UE shall generate an initial INVITE request as specified in 
ES 283 003 [20] for an originating UE. The Request-URI in the INVITE request shall be the well known PSI (Public 
Service Identifier) of the BC Service. If the UE supports the SIP INFO framework, as defined in 
draft-ietf-sipcore-info-events-08 [i.l5], the UE shall indicate so by including Recv-Info header in the INVITE with a 
value set to 'nil'. 

Note that the inclusion of the Recv-Info header is the indication that the UE supports the SIP INFO framework. If the 
UE does support the reception of other INFO packages (for other applications), and it wishes to indicate so, it can 
replace the value nil with the appropriate list of INFO packages. 
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Note that the draft defines a mechanism for backward compatibiHty when one end in the SIP dialog supports the SIP 
INFO framework while the other peer does not support the SIP INFO framework. Clause 9 in the draft details co- 
existence within a SIP dialog of legacy SIP INFO and SIP INFO based on the SIP INFO framework. 

An SDP Offer shall be included in the request. The SDP offer shall be done in accordance with the parameters received 

during UE service selection procedure and with media capabilities and required bandwidth available for the BC session. 
If the user desires to join a BC service outside of this negotiated set of channels, a session modification is required. 

The SDP offer at media level shall include the following elements: 

• The m-line(s) shall be set according to the mapping defined in clause L.2 for the BC service which the UE 
intends to join first. 

• The c-line(s) shall be set according to the mapping defined in clause L.2 for the BC service which the UE 
intends to join first. 

• An a=bc_service:BCServiceId line to indicate the BC service which the UE intends to join first. 

• Optionally one or more a=bc_service_package attributes (see below) as defined in annex N. In the first initial 
offer it shall not contain mult_list and bc_service_id list parameters. If the initiation is the result of a 
previously denied initiation the UE may restrict the BC services by including mult_list. 

• If the UE has knowledge of the largest bandwidth of aU the BC services included in the session, the b-line 
shall be included and set to this value. 

• An a=recvorLly Une. 

Additionally, EEC streams may be defined, as described in clause 5.1.3.1.1. 

When the UE receives any SIP request or response, and if the UE supports the SIP INFO framework, it shall look for 
the Recv-Info header. 

If the header is present then the UE shall follow the network request as set in the header, to report/not report the selected 
channel. 

If the header is absent, then the UE may optionally report the selected channel outside the SIP INFO framework. 

The UE shall then examine the media parameters in the received SDP. The UE shall restrict the BC services that it joins 
according to the a=bc_service_package parameters received from the SCF. If the UE has retrieved the IPTV User 
profile prior to BC session initiation, it may ignore the a=bc_service_package parameters, if present (see clause 5.3.1.1). 

If the user desires to join a BC service outside of this negotiated set, a session modification is required. 

If the UE receives a 488 error code with warning 370 Insufficient Bandwidth the UE may perform a new SIP INVITE 
with a lower maximum bandwidth for BC service the UE intends to join. This procedure may be repeated. If no 
agreement can be reached the UE may display a failure message to the user. 

When the UE receives the SIP final response, the UE shall joins the multicast channel according to the a=bc_service 
line. 

5.1 .3.1 .1 Additional SDP lines for FEC streams 

When the UE decides to connect to FEC stream(s) associated to the original BC stream(s), it shall include additional 
SDP lines in the SDP offer as follows: 

• One or more m line(s) for each FEC stream exposed through the SSF: 

It shall be set according to the mapping defined in clause L.2. 
It shall contain a c-line according to the mapping defined in clause L.2. 
If the BC content is defined through a single m-line, a grouping line may be included. 

If the BC content is defined through several m-hnes, grouping line(s) shall be included, one for each BC m-line that is 
associated to a FEC stream. 
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The grouping line uses the "FEC" semantic as defined in RFC 5956 [25]: 

• a=group:FEC:<original stream id> <FEC stream id> 

The present document supports only the DVB-IP AL-FEC Base layer, so there can be only one <FEC stream 
id> associated to an original stream. 

The original stream id shall reflect the value held by the media description of one stream in its a=mid 
attribute. 

The FEC stream id shall reflect the value held by the media description of the DVB-IP AL-FEC Base 
layer FEC stream (associated to the original stream) in its a=mid attribute. 

Furthermore, when grouping line is included, there shall be an additional media identification attribute within the m-hne 
of the original stream that is within the grouping: 

• a=mid:<original stream id>. 

5. 1.3.1 A SCF-initiated session initiation 

The UE shall support the procedures specified in ES 283 003 [20] for handling sessions. 

Upon receipt of SIP INVITE request, and if the UE supports the SIP INFO framework, it shall look for the Recv-Info 
header. 

If the header is present then the UE shall follow the network request as set in the header, to report/not report the selected 
channel. 

If the header is absent, then the UE may optionally report the selected channel outside the SIP INFO framework. 

The UE then checks the P-Asserted-Identity header for a well-formed PSI of the BC service, and the SDP parameters to 
determine that it is a BC session initiation request. In particular: 

• The UE shall examine the a=bc_service parameter. This parameter contains the BCServiceld (channel) the 
SCF wants the UE to join. 

• If present it shall examine the a=bc_service_package attributes and store the attributes. If the UE has retrieved 
the IPTV User profile prior to BC session initiation, it may ignore the a=bc_service_package parameters. 

• It shall examine the c-Une(s) and extract the IP multicast address to determine that it is a multicast session. 

• If the UE has a pre-configured maximum bandwidth limitation, it shall examine the b-line parameter and 
verify if it not exceeds the pre-configured value. If the value is exceeded, the UE shall answer with a 403 error 
code. 

The UE shall check the if SDP parameters in the offer are acceptable (e.g., codecs), the UE shall answer with a SIP 200 
OK, indicating the SDP answer as follows: 

• The c-lines and m-hnes shall be identical to ones indicated in the SDP offer. 

• It shall include an a=recvonly attribute. 

• It shall include a b-hne parameter with the same value as in the offer. 

• If the SDP offer includes one or more a=bc_service_package attribute the UE answer shall include the same 
attributes. 

Finally, if the UE supports the SIP INFO framework, and if the SCF indicated, as well, support for the SIP INFO 
framework as described in the processing above, the UE shall indicate the same support. For that purpose, the UE shall 
include the Recv-Info header in the SIP 200 OK with a value set to 'nil'. 

When the UE receives an acknowledgement, the UE shall join the multicast channel according to the multicast address. 



ETSI 



33 



ETSI TS 183 063 V3.5.1 (2011-02) 



5.1.3.2 



Session modification 



When there is a need for BC session modification, the UE shall generate a re-INVITE request or an UPDATE request, 
depending on the dialogue state, as specified in ES 283 003 [20] for an originating UE. 

The UE shall include SDP offer in session modification request. When the modified session is also a broadcast session 
the format of the SDP shall be the same as for a session initiation. 

Upon receipt of a re-INVITE request or an UPDATE request, the UE shall follow the procedures defined in 
ES 283 003 [20] for an originating UE. 

When receiving SDP offer, the SDP answer shall reflect the media capabilities and required bandwidth as available for 
the BC session. The selection of the channels that are above the negotiated bandwidth may require a new session 
modification in accordance with the behaviour of the UE. 



When supporting BC service with trick play, the BC session can observe two special cases: 

• The Broadcast session is modified to change from Multicast to unicast flow. This is the case in which the UE 
activates the trick play mode. 

• The Broadcast session with trick play mode is modified to return to normal Broadcast TV. This is the case in 
which the UE deactivates the trick play mode by, e.g. switching channels from a paused channel to another 
Uve Broadcast TV channels. 



Upon activation of trick-play mode, the UE shall perform session modification as described in clause 5.1.3.2. 

The UE shall include an SDP offer with previously negotiated media descriptions with the port set to zero and two or 
more additional media descriptions: one for RTSP control and one or more for the unicast streams. The RTSP control 
media descriptor shall follow ES 283 003 [20]. The SDP offer for media delivery shall be identical to the previous SDP 
offer done for broadcast in term of codecs and transport protocol. 

The "t=" line in the SDP offer shall include a reference timestamp for when trick mode was activated. The "t=" hne 
shall be used by the network to calculate the h-offset that is returned in the SDP answer. By including the reference 
timestamp, the network can provide a more accurate h-offset independent of clock synchronizations issues. If the "t=" 
line in the SDP offer is set to "0 0" the h-offset shall be calculated based on the timestamp for when the re-INVITE is 
processed by network. The SDP answer shall include the same value as in the "t=" line as in the SDP offer. If the "t=" 
line in the SDP answer is set to "0 0" the UE assumes the h-offset was calculated based on network reference 
timestamp. 

The UE shall also include the following Service Action Data: 

• IPTVActionDataConomand shall be set to "SwitchToTM" . 

• SwitchToTM shall be set to "IPTVBcActionData" . 

BCServiceld shall present only if the UE has not informed the SCF of the selected channel prior to this procedure (as 
defined in clause 5.1.3.5) and set to the value of the current channel. 

When the UE acknowledges the SIP 200 OK with an ACK message, the UE may start playback (see clause 7). 
5.1 .3.3.2 Trick-play mode deactivation 

Upon deactivation of trick-play mode, the UE shall perform session modification as described in clause 5.1.3.2. 

The UE shall include an SDP offer with previously negotiated RTSP and unicast media descriptions with the port set to 
zero. The SDP corresponding to the broadcast session shall be reactivated (i.e. port not set to zero). The "t=" line in the 
SDP offer shall be set to "0 0". 



5.1.3.3 



BC service witli trick-play mode 



5.1.3.3.1 



Trick-play mode activation 



ETSI 



34 



ETSI TS 183 063 V3.5.1 (2011-02) 



The UE shall also include the following Service Action Data: 

• IPTVActionDataCommand shall be set to "SwitchToBC". 

• SwitchToBC shall be set to "IPTVBcActionData" . 

• BCServiceld is set to the value of the selected channel. 

The UE deactivates trick-play mode when it receives an indication from the network that it has caught up with the live BC 
service. 

The UE shall go back to normal BC session if it does not receive any dehvery data anymore and has not paused 
playback. 

5.1 .3.4 Session termination 

Upon a request for a BC session termination, the UE shall generate a BYE request as specified in ES 283 003 [20] for 
an originating UE. 

Upon receipt of a BYE request the UE shall follow the procedure specified in ES 283 003 [20] for an originating UE. 

5.1.3.5 Session Information 

During the procedures for join multicast group (clause 8.1.1) the UE may inform SCF of the selected channel. 

If both the UE and the SCF support the INFO Framework and the UE was not authorized by the SCF during the session 
initiation setup to send information of the selected channel, then the UE shall not report the selected channel. 

If both the UE and the SCF support the INFO Framework and the UE was authorized by the SCF during the session 
initiation setup to send information of the selected channel, then the UE shall proceed as described below. 

To that effect, the UE shall reset a delay timer after successfully viewing a new channel using the procedure for joining 
multicast group (clause 8.1.1). The delay timer is a preconfigured value in the UE with a default value of 10 seconds. 
When the delay timer expires, the network shall be informed of the currently viewed channel with a SIP INFO message 
including the appropriate info package. 

NOTE: A formal definition of the INFO package for reporting the selected BC channel is out scope of the current 
release. 

• The SIP INFO message based on the SIP INFO framework draft as defined in draft-ietf-sipcore-info-events-08 
[i. 15] shall be sent by the UE on the same dialogue as the Broadcast TV session initiation and shall contain an 
info package that is based on XML file schema that includes the channel change information. The service 
action data: the matching "BC Bookmarks" object shall be created so that: 

IPTVActionDataCommand shall be set to "Notify" . 

Notify shall be set to "IPTVBcActionData" . 

BCServiceld is set to the value of the current channel. 
Programmeld is optionally set to the value of the current programme. 

• Bookmark is set to the current timestamp if the UE has the knowledge of such timestamp (e.g. through SNTP). 
If the UE is not aware of such current timestamp. Bookmark is set to a default value: "NOW". 

The Content-Type header shall be set to "application/vnd.etsi.iptvcommand H-xml". The body content of the message is 
described in annex D. 

The Content-Type header shall be set to "application/vnd.etsi.iptvcommand +xnil". The XML schema is described in 
annex D. 

If the UE does not support the INFO Framework, the UE may inform the SCF of the selectd channel. 
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To that effect, the UE shall reset a delay timer after successfully viewing a new channel using the procedure for joining 
multicast group (clause 8.1.1). The delay timer is a preconfigiu-ed value in the UE with a default value of 10 seconds. 
When the delay timer expires, the network shall be informed of the currently viewed channel with a SIP INFO message. 

• The SIP INFO message shall be sent by the UE on the same dialogue as the Broadcast TV. 

• Session initiation and shall contain an XML schema with the channel change information. The message body 
carries the service action data: the matching "BC Bookmarks" object shall be created so that: 

IPTVActionDataCommand shall be set to "Notify" . 

Notify shall be set to "IPTVBcActionData". 

BCServiceld is set to the value of the current channel. 

Programmeld is optionally set to the value of the current programme. 

• Bookmark is set to the current timestamp if the UE has the knowledge of such timestamp (e.g. through SNTP). 
If the UE is not aware of such current timestamp. Bookmark is set to a default value: "NOW". 

The Content-Type header shall be set to "application/vnd.etsi.iptvcommand H-xml". The body content of the message is 
described in annex D. 

5.1 .3.6 Procedure for PPV service 

5.1 .3.6.1 PPV Session initiation 

The PPV may use session initiation of BC as described in clause 5.1.3.1, with the following differences: 

The Request-URI in the INVITE request shall be the well known PSI (Pubhc Service Identifier) of the BC Service 
which the PPV service belongs to. 

The differences in the SDP offer at media level: 

• The m-Une(s) shall be set according to the mapping defined in clause L.2 for the BC Service which the PPV 
service belongs to. 

• The c-line(s) shall be set according to the mapping defined in clause L.2 for the BC Service which the PPV 
service belongs to. 

• An a=bc_service:BCServiceId line to indicate the BC service which the PPV service belongs to. 

• An a=bc_program:BCprogramld line to indicate the BC program which the PPV service is, and shall be set 
according to the mapping defined in clause L.2.2A. 

5.1.3.6.2 PPV Session termination 

When the PPV program ends or UE wants to terminate the session, the UE shall generate a BYE request as specified in 
ES 283 003 [20] for an originating UE, which is similar with BC session termination as described in clause 5.1.3.4. 

Upon receipt of a BYE request, the UE shall follow the procedure specified in ES 283 003 [20] for an originating UE, 
which is similar with BC session termination as described in clause 5.1.3.4. 

5.1 .4 Procedure for CoD service 

5.1 .4.1 Procedure for retrieving missing parameters before session initiation 

In case of procedure for establishing the content control and content deUvery at the same time see clause 5.1.4.2.1. If the 
UE does not have all transport parameters (RTP or UDP transport for MPEG2TS encapsulation or direct RTP, FEC 
layers addresses and ports) the UE shall send a SIP OPTIONS message, 

NOTE: It is an operator choice to provide preconfigured transport parameters values, manual configuration 
mechanisms, etc., if the transport information is not retrieved from the SSF. 
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The "Request-URI" is related to the CoD session that the user wants to activate. The Request-URI shall be composed of 
a user and domain part as defined as follows: 

• The user part contains the content identifier in a free string format, as defined in TS 182 027 [2]. 

• The domain part is the Service Provider domain name, obtained from SSF. 

The content identifier shall be retrieved from service selection information (see annex L concerning the mapping 
between service selection information and SIP/SDP parameters). 

The TO header shall contain the same URI as in the "Request-URI" parameter. 

The FROM header shall indicate the pubUc user identity of the user. 

Upon reception of the SIP 200 OK including SDP, the UE shall initiate COD session as described in clause 5.1.4.2. 

5.1.4.2 UE-initiated session initiation 

The UE shall support the procedures specified in ES 283 003 [20] for originating sessions. 

Upon a request for a COD session initiation, the UE shall generate an initial INVITE request as specified in 

ES 283 003 [20] for an originating UE. 

The "Request-URI" is related to the CoD session that the user wants to activate. The Request-URI shall be composed of 
a user and domain part as defined as follows: 

• The user part contains the content identifier in a free string format, as defined in TS 182 027 [2]. 

• The domain part is the Service Provider domain name, obtained from SSF. 

The content identifier shall be retrieved from service selection information (see annex L concerning the mapping 
between service selection information and SIP/SDP parameters). 

The TO header shall contain the same URI as in the "Request-URI" parameter. 

The FROM header shall indicate the pubhc user identity of the user. 

5.1 .4.2.1 Procedure for establishing tine RTSP content control and content delivery channel 

5.1.4.2.1.1 UE as SDP offerer 

An SDP Offer shall be included in the initial INVITE request. The SDP offer shall be done in accordance with media 
capabilities and policies available for the CoD session and with the parameters received from the SSF during UE 
service selection procedure (see annex L concerning the mapping between service selection information and SIP/SDP 
parameters) or from the SIP OPTIONS response. 

The SDP offer from the UE shall contain a media description for the RTSP content control channel and one for the 
content delivery channel. 

SDP session level parameters shall be used as specified in ES 283 003 [20]. 

The RTSP content control media description shall be carried by TCP and follow ES 283 003 [20]. The SDP parameters 
for the RTSP content control channel shall be set as follows: 

• a "m" Une for an RTSP stream of format: m=<media> <port> <transport> <fmt>: 

The media field shall have a value of "appUcation" . 

The port field shall be set to a value of 9, which is the discard port. 

The transport field shall be set to TCP or TCP/TLS. The former is used when RTSP runs directly on top 
of TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. 
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The fmt parameter shall be included and shall be set to iptv_rtsp 
(ex. m=application 9 tcp iptv_rtsp). 



• An "a=setup" attribute shall be present and set to "active" as defined in ES 283 003 [20] 
(ex. a=setup : active). 

• An "a= connection" attribute shall be present and set as "new" as defined in ES 283 003 [20] 
(ex. a=connection : new). 

• A "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP 
address of the flow of the related RTSP content control 

(ex. c = IN IP4 <IP_ADDRESS>). 

NOTE: RTSP over UDP is out of scope of the present document. 

For each media stream controlled by the RTSP content control channel the SDP offer shall include a content deUvery 
channel media description set as follows: 

• The "m=" line indicates the type of the media, the transport protocol and the port of the related content 
delivery channel. It may also include a fmt parameter which shall indicate the format given by the SSF, a 
subset of them or the format offered by the UE if none is given by the SSF. 

• The "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and 
unicast address of the flow of the related content delivery channel, 

(ex. c=IN IP4 <IP_ADDRESS>) . 

• The "b=" line shall contain the proposed bandwidth. If the user has fetched the bandwidth required for this 
particular content dehvery channel during service selection procedure, the bandwidth attribute at media level 
shall be set to this value. Otherwise, this attribute shall be set to a pre-configured value 

(ex. b=AS : 15000) . 

• An "a=" line with a "recvonly" 



Additionally, EEC streams may be defined, as described in clause 5.1.4.2.3. 

When receiving any SIP response, the UE shall examine the media parameters in the received SDP: the UE shall fetch 
the RTSP session ID from the "fmtp:iptv_rtsp h-session" attribute if present in the received SDP answer contained in 
the SIP response. This RTSP session ID shall be used for in RTSP media control messages and the UE shall 
subsequently use RTSP Method 1 for CoD playback control as described in clause 7.1.1. If fmtp:iptv_rtsp h-offset is 
specified in the SDP from MCF, the UE may use this as appropriate in subsequent RTSP media control messages. 

If no "fmtp:iptv_rtsp h-session" parameter was received in the SDP answer, the UE shall use RTSP method 2 for CoD 
playback control as described in clause 7.1.2. 

5.1 .4.2.2 Procedure for establishing the RTSP channel separately 



(ex. a=recvonly). 



5.1.4.2.2.1 



UE as SDP offerer 



The INVITE request shall contain an SDP offer of media description only for the RTSP channel. 



The SDP session level parameters shall be used as specified in ES 283 003 [20]. 



The SDP parameters for the RTSP channel shall be set as follows: 



A "m" line for an RTSP stream of format: m=<media> <port> <transport> <fmt>: 



The media field shall have a value of "appUcation". 



The port field shall be set to a value of 9, which is the discard port. 



The transport field shall be set to TCP or TCP/TLS. The former is used when RTSP nms directly on top 
of TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP: 
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■ The fmt parameter shall be set to iptv_rtsp. 

• An "a=setup" attribute shall be present and set to "active" as defined in ES 283 003 [20]. 

• An "a= connection" attribute shall be present and set as "new" as defined in ES 283 003 [20]. 
NOTE: RTSP over UDP is out of scope of the present document. 

5.1 .4.2A SCF-initiated session initiation 

The UE shall support the procedures specified in ES 283 003 [20] for terminating sessions. 

Upon receipt of SIP INVITE request, the UE shall check the P-Asserted-Identity header for a well known PSI of the 
CoD service. 

If the UE does not already have all transport parameters to compose an SDP offer, the UE shall use SIP OPTIONS to 
retrieve missing parameters (e.g. RTP or UDP transport for MPEG2TS encapsulation or direct RTP, bandwidth, FEC 
layers addresses and ports). 

An SDP offer shall be included in the SIP 200 OK. The SDP offer shall be done in accordance with media capabilities 
and policies available for the CoD session and with the parameters received from the SSF during UE service selection 
procedure (see annex L concerning the mapping between service selection information and SIP/SDP parameters). 

The SDP offer from the UE shall contain a media description for: 

• either the RTSP content control channel as described in clause 5.1 .4.2.2; or 

• for the RTSP content control channel and one for the content delivery channel as described in clause 5.1.4.2.1. 
SDP session level parameters shall be used as specified in ES 283 003 [20]. 

When the UE receives the ACK, the UE shall examine the media parameters in the received SDP: the UE shall fetch the 
RTSP session ID from the "fmtp:iptv_rtsp h-session" attribute if present in the received in the SDP answer contained in 
the ACK. This RTSP session ID shall be used for in RTSP media control messages and the UE shall subsequently use 
RTSP Method 1 for CoD playback control as described in clause 7.1.1. If fmtp:iptv_rtsp h-offset is specified in the SDP 
answer contained in the ACK, the UE may use this as appropriate in subsequent RTSP media control messages. 

If no "fmtp:iptv_rtsp h-session" parameter was received in the SDP answer, the UE shall use RTSP method 2 for CoD 
playback control as described in clause 7.1.2. 

5.1 .4.2.3 Additional SDP lines for FEC streams 

When the UE decides to connect to FEC stream(s) associated to the COD original stream, it shall include additional 
SDP lines in the SDP offer as follows: 

• One or more m-hne(s) for each FEC stream exposed through the SSF: 

It shall be set according to the mapping defined in clause L.3. 
It shall contain a c-line according to the mapping defined in clause L.3. 
If the COD content is defined through a single m-Une, a grouping Une may be included. 

If the COD content is defined through several m-lines, grouping line(s) shall be included, one for each COD m-line that 

is associated to a FEC stream. 

• a=group:FEC:<original stream id> <FEC stream id> 

The present document supports only the DVB-IP AL-FEC Base layer, so there can be only one <FEC stream 
id> associated to an original stream: 

The original stream id shall reflect the value held by the media description of one stream in its a=mid 
attribute. 

The FEC stream id shall reflect the value held by the media description of the DVB-IP AL-FEC Base 
layer FEC stream (associated to the original stream) in its a=mid attribute. 
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Furthermore, when grouping line is included, there shall be an additional media identification attribute within the m-Une 
of the original stream that is within the grouping: 

• a=nud:<original stream id>. 

5.1.4.3 Session modification 

In order to modify the session from the UE side, the UE shall send a re-INVITE or an UPDATE request as specified in 
ES 283 003 [20] for an originating UE. 

The UE shall not modify RTSP channel m-line description in the SDP if the media delivery streams controlled by RTSP 
are not removed (port not set to zero in m-lines) in the SDP. 

Upon receipt of a re -INVITE request or an UPDATE request, the UE shall modify the session as specified in 
ES 283 003 [20] if the request is acceptable to the UE. 

5.1 .4.3.1 Procedure for establishing tine content delivery channel 

5.1.4.3.1.1 UE as SDP offerer 

The UE shall send a re-INVITE or an UPDATE request containing SDP offer after acquiring the network parameters 
via RTSP DESCRIBE as specified in clause 7.1.2.2 in order to establish the content delivery chaimels. The media 
descriptions of content delivery channels shall be populated as follows: 

• Media descriptions acquired by DESCRIBE response are appended after the media description of RTSP 
channel. 

• The port number in "m=" line shall be replaced by the real receiving port of the UE. 

• "a=recvonly" attribute shall be inserted if the attribute is not specified. 

• Remove "a=" lines specific to RTSP (a=control, a=range, and a=etag). 

• If "c=" hnes are specified in media descriptions, the addresses of "c=" lines shall be replaced by the address of 
theUE. 

The SDP parameters for the RTSP channel shall be set to the same parameters as specified in clause 5.1.4.2.2.1 except 
for the "a=connection" attribution. The attribution shall be set to "existing" as defined in ES 283 003 [20]. 

The SDP offer shall include one or more media description sets as follows: 

• The "m=" line indicates the type of the media, the transport protocol and the port on which the UE has to 
received the flows of the related content delivery channel. It may also include a fmt parameter which shall 
indicate the format given by the network parameters. 

• The "c=" Une shall include the network type with the value set to IN, the address type set to IP4 or IP6, and 
unicast address of the flow of the related content delivery channel. These values are given by the network 
parameters. 

• The "b=" line shall contain the bandwidth. The bandwidth attribute shall be set to this value given by the 
network parameters. 

• An "a=" line with a "recvonly". 

Additionally, EEC streams may be defined, as described in clause 5.1.4.3.2. 

5.1 .4.3.2 Additional SDP lines for FEC streams 

When the UE decides to connect to FEC stream(s) associated to the COD original stream, it shall include additional 
SDP lines in the SDP offer as follows: 

• One or more m-Une(s) for each FEC stream exposed through the SSF: 

It shall be set according to the mapping defined in clause L.3. 
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It shall contain a c-line according to the mapping defined in clause L.3. 

• If the COD content is defined through a single m-line, a grouping line may be included. 

If the COD content is defined through several m-lines, grouping line(s) shall be included, one for each COD m-line that 
is associated to a FEC stream. 

The grouping Une uses the "FEC" semantic as defined in RFC 5956 [25]: 

• a=group:FEC:<original stream id> <FEC stream id>. 

The present document supports only the DVB-IP AL-FEC Base layer, so there can be only one <FEC stream 
id> associated to an original stream: 

The original stream id shall reflect the value held by the media description of one stream in its a=mid 
attribute. 

The FEC stream id shall reflect the value held by the media description of the DVB-IP AL-FEC Base 
layer FEC stream (associated to the original stream) in its a=mid attribute. 

Furthermore, when grouping line is included, there shall be an additional media identification attribute within the m-hne 
of the original stream that is within the grouping: 

• a=mid:<original stream id>. 

5.1.4.4 Session termination 

The session termination will differ when using RTSP "Method 1" or RTSP "Method 2" as described in clauses 5.1.4.4.1 
and 5.1.4.4.2. The different RTSP methods are described in clause 7 and annex Q. 

5.1 .4.4.1 Session termination using RTSP Metliod 1 

In order to terminate the session, the UE shall first close the RTSP session that was established during session initiation 
by closing the underlying TCP connection and then send a BYE request as specified in ES 283 003 [20]. 

Upon receipt of a BYE request, the UE shall then terminate the session as specified in ES 283 003 [20]. 

5.1 .4.4.2 Session termination using RTSP Metliod 2 

In order to terminate the session, the UE shall send a BYE request as specified in ES 283 003 [20]. The media teardown 
procedures using RTSP TEARDOWN as described in clause 7.1.2.6 shall be executed before the BYE is sent out. This 
would ensure that the BYE request does not close the RTSP content control channel ports at transport layer before 
RTSP TEARDOWN is sent. 

Upon receipt of a BYE request, the UE shall send a TEARDOWN request to terminate the RTSP session if 
non-persistent RTSP connection is used or if the TCP connection is open. The UE shall then send a SIP 200 OK 
response to the BYE request as specified in ES 283 003 [20]. 

NOTE: The UE may not be able to send TEARDOWN or receive a response for TEARDOWN when the resource 
in the network for RTSP session has been released when of receiving SIP BYE. 

5.1 .4.5 Procedures for handling COD Service action data 

When a user requests to stop viewing a CoD with the intention of resuming it later, i.e. to 'park' the CoD stream 
(bookmark it to allow it be resumed later) and to tear down the session, the UE should send a SIP INFO request to the 
SCF. The content of that INFO request shall be as follows: 

• The value of the Request-URI shall be set to the one used in the related session. 

• From and To headers shall be set to the one defined during the session initiation procedure. 

• Call-ID shall be set to the same value as that of the CoD session. 

• CSeq shall be generated by UE following rules defined in ES 283 003 [20] for request within a dialog. 
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• The Content-type header shall include the registered MIME type of XML documents representing IPTV 
service action data: "application/vnd.etsi.iptvcommand+xml". 

• The message body carries the service action data: 

IPTVActionDataCommand shall be set to "Notify" . 
Notify shall be set to "IPTVCodActionData" . 

The matching "Available CoD" object shall be updated so that CoDDeliveryStatus is set to "Parked" and 
CoDOffset is set to the current reading cursor of the content. 

NOTE: The XML schema mapping to the MIME type: "appUcation/vnd.etsi.iptvsad-cod+xml" is available in 
annex K of the present document. 

When a user is making a request that allows for some type of content insertion, i.e. without tearing down the session, 
the UE should send a SIP INFO request to the SCF. This may be during the pausing of content, to allow some other 
content to be played during the pause. The content of that INFO request shall be as follows: 

The value of the Request-URI shall be set to the one used in the related session. 

From and To headers shall be set to the one defined during the session initiation procedure. 

Call-ID shall be set to the same value as that of the CoD session. 

CSeq shall be generated by UE following rules defined in ES 283 003 [20] for request within a dialog. 

The Content-type header shall include the registered MIME type of XML documents representing IPTV 
service action data: "application/vnd.etsi.iptvcommand-nxml". 

The message body carries the service action data: 

1) IPTVActionDataConomand shall be set to "Notify" . 

2) Notify shall be set to "IPTVCodActionData" . 

3) The matching "Available CoD" object shall be updated so that CoDDeliveryStatus is set to "Paused", the 
expected duration is set to its value and CoDOffset is set to the current reading cursor of the content. 

NOTE 1: How to determine expected pause duration is up to the implementor of the UE. 

NOTE 2: The XML schema mapping to the MIME type: "appUcation/vnd.etsi.iptvsad-cod-nxml" is available in 
annex K of the present document. 

NOTE 3: Content insertion may still be performed on the UE and/or MF side, regardless of this procedure being 
used. 



5.1 .5 Procedure for Service Configuration 

The UE uses the XCAP to manage the IPTV user profile (see clause 6.1.2). In order to keep the IPTV User Profile data 
synchronized with the network elements and other terminals that the user might be using, the UE should subscribe from 
the SCF to changes in the XCAP IPTV documents. 

NOTE: Changes may result from XCAP manipulation and/or operator's action. 

5.1 .5.1 Subscription to notification of clianges 

If subscription to notification of changes is used, the UE shall generate a SUBSCRIBE request in accordance with 
references [26] and [15]. 

The contents of the SUBSCRIBE request shall be as follows: 

• The value of the Request-URI shall be set to the IMS public user identity associated to the profile or to a 
pre-configured value or to a value received from the CNGCF. 
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• The From header shall be set to the IMS public user identity associated to the profile. 

• The To header shall be set to a URI that identifies the IPTV service provider (e.g. PSI). 

• The Accept header shall include the following values: 

application/xcap-diff+xml. 

• The Event header shall be set to the "xcap-diff event package. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. 

The UE shall automatically refresh the subscription, either 600 seconds before the expiration time if the initial 
subscription was for greater than 1 200 seconds, or when half of the time has expired if the initial subscription was for 
1 200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall 
still consider the original subscription vahd for the duration of the most recently known "Expires" value according to 
ES 283 003 [20]. Otherwise, the UE shall consider the subscription invahd and start a new initial subscription according 
toES 283 003 [20]. 

5.1 .5.2 Processing of notifications 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription, the UE shall look for a 
message body with a content-type header indicating "application/xcap-diff-Hxml" stores its contents for further 
processing and return a SIP 200 OK response to the NOTIFY request. 

5.1 .6 Procedure for IPTV presence service 

If presence service is used, the UE shall implement the role of a PUA as specified in ES 283 030 [21]. 

Publication of IPTV specific information in presence document depends on user-configurable data stored in the user 
equipment. 

Depending on the user configuration, the UE may send a SIP PUBLISH request in the following cases: 

On receipt of a final SIP 200 OK concerning a BC session initiation procedure. 

On receipt of a final SIP 200 OK concerning CoD session initiation procedure. 

On receipt of a final SIP 200 OK concerning N-PVR content session initiation procedure. 

On receipt of a final SIP 200 OK concerning an IPTV session teardown procedure. 

During a BC session, the UE may also send a PUBLISH request after having performed a channel-change (i.e. sending 
IGMP or MLD request for a particular BC service) or after the timer Tec associated to the channel change has elapsed if 
this timer is activated as described in annex M. 

NOTE 1 : In order to decrease the data size and reduce the redundancy of IPTV service access history data, it is 
recommended that UE send the PUBLSIH request based on the user's request or based on local pohcy, 
e.g. send service information every 10 minutes or vmder the user's indication to send out the request, 

which is out scope of the present document. 

When activated, the timer Tec is triggered at every channel-change. 
The content of the PUBLISH request shall be as follows: 

The Request-URI of the To and From headers shall be set to the public user identity of the user. 

The Event header shall be set to the "presence" event package. 

The content type shall be set to "apphcation/pidf +xnil". 
The presence XML document included in the PUBLISH body shall conform to ES 283 030 [21]. 
The "Entity" element shall be present and set to the public user identity of the user. 
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The "Activity" element shall be present and set to "TV". 



Additional IPTV presence elements are defined in annex E and may be included in the presence documents pubhshed 
by the UE: 

• The "BCServicePresence" element is part of the "tuple" component according to the presence data model. It is 

composed of: 

"CurrentBCServicelD" element: it indicates the currently activated BC service. 
"CurrentBCProgramID" element: it indicates the currently watched program. 

• The "CoDServicePresence" element is part of the "tuple" component according to the presence data model. It 

is composed of: 

"CurrentCoDContentID" element: it indicates the currently watched CoD content. 

• The "NPVRServicePresence" element is part of the "tuple" component according to the presence data model. It 

is composed of: 

"CurrentNPVRContentID" element: it indicates the currently watched N-PVR content. 

• The "ServiceAccessHistoryPresence" element is part of the "tuple" component and the 
"ServiceAccessHistorylD" element is the 'id' attribute according to the presence data model. It is composed of: 

"ServiceType" element: it indicates the service type of the watched IPTV service. 

"ReferencedContentID" element: it identifies the associated content in the context of specific 
ServiceType. 

"Rating" element: it indicates the user rating for the referenced content. 
"AccessStartTime" element: it indicates the time accessing the IPTV service. 
"AccessEndTime" element: it indicates the time when the access of the IPTV service is ended. 
"HistoryExpireTime" element: it indicates the expiring time of the IPTV service access history item. 

• The "ServiceStateDataPresence" element is part of the "tuple" component and the "ServiceStateDatalD" 
element is the 'id' attribute according to the presence data model. It is composed of: 

Zero or more "IPTVServiceState" elements, which identify the services that the SSC is composed of. The 
"IPTVServiceState" element is composed of: 

■ "ServiceType" element: it indicates the service type of the watched IPTV service. 

■ "ReferencedContentID" element: it identifies the associated content in the context of specific 

ServiceType. 

■ "ServiceState" element: it contains service state information that can be enumerated, e.g. trick play 
status or - commands. 

■ "ServiceStatelnformation " element: it contains additional service state information, e.g. state 
(transition) history. 

■ "ServiceStateExpiryTime " element: it indicates the expiry time of the IPTV Service State. The 
default value of ServiceStateExpiryTime indicates that it expires when the associated ongoing 
service is terminated. 

If the ServiceType element has the value "BC", then the following element is applicable. 

■ "TrickPlayActivated" element: it indicates whether BC trickplay is activated. 

If the IPTVServiceTypeldentifier has the value "SSC", then the following elements are applicable. 

■ "SSCRoomID" element: it identifies the SSC Room for Shared Service Control. 
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■ "IPTVServiceState" element: it identifies the services that the SSC is composed of. The 

"IPTVServiceState" element is described above. 

If the IPTVServiceTypeldentifier has the value "PSC", then the following elements are applicable. 

■ "PSCid" element: it identifies a specific PSC service for Personalised Service Composition. 

■ "IPTVServiceState" element(s), which identify the services that the PSC is composed of. The 
"IPTVServiceState" element is described above. 

NOTE 2: The data model for SSC - and PSC Service State follows the so-called "composite design pattern". The 
individual BC and CoD Service States have their own ServiceState and ServiceStatelnformation 
attributes, which are associated in the combined SSC - or PSC Service State. 

NOTE 3: The collection of Service State Data (from UE, network elements, external applications and/or other) is 
outside the scope of the present document. 

NOTE 4: The availability of Service State Data is optional, as indicated in TS 182 027 [2]. 

In the XML document, each service is described thanks to the "service-description" OMA parameter as specified in 
OMA-TS-Presence-SIMPLE-Vl [23]. A new "service-id" is defined for this purpose with the following values 
IPTV-BC, IPTV-CoD, IPTV-NPVR, IPTV-SAH, IPTV-SSD. 

A "class" parameter can also be added with the value "IPTV". 

The activation/deactivation of this service is reported thanks to the "status parameter present in the relevant "tuple. 

An example of the use of this parameter in the XML document is described in annex E. 

The IPTV presence authorization rules and common policy shall be in conformance with the OMA-TS- 
Presence_SIMPLE_XDM-V2_0 [54], RFC 5025[53] and RFC 4745[52]. 

NOTE 5: Additional privacy and regulatory aspects affecting presence management and pohcy mechanisms are 
outside the scope of present document. 

5.1.6.1 Subscribing to presence 

When the UE intends to retrieve one user's IPTV presence, it shall generate a SUBSCRIBE request for the "presence" 
event package as specified in ES 283 030 [21]. 

When the UE indicates to retrieve the IPTV service access history attribute or the IPTVServiceStateData attribute of the 
presence, the SUBSCRIBE request shall contain a message body for defining the SAH or the SSD information as the 
preferred notification information to be delivered. The contents of the SUBSCRIBE request shall be as follows: 

• The content Type header shall be set to "appUcation/simple-filter+xml". 

• A message body shall be present for defining the structure of the filter criteria, and the filter criteria is present 
as an XML document as follows: 

1) The <what> element shall be included, containing one or more <include> elements. 

2) The <include> element shall include a <type> attribute with the value of "xpath", and the value of the 
<include> element shall be set to "/presence/tuple/SAH" or "/presence/tuple/SSD". 

3) The <trigger> element may be included, containing one or more <changed> elements. 

4) The <changed> element may include <from> and <to> attribute, and the <changed> element may be set 
to "/pidf:SAH/pidf:AccessStartTime" 
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Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. The UE shall automatically 
refresh the subscription before the expiration time expires according to RFC 3265 [69]. 

The filter criteria complies to "Functional Description of Event Notification Filtering" [40] and "An Extensible Markup 
Language (XML)-Based Format for Event Notification Filtering" [41]. 

5.1.6.2 Receiving presence notifications 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription, the IPTV application within 
the UE shall parse the XML document contained in the message body to retrieve and display the presence information. 

5.1 .7 Procedure for PVR Service 

5.1 .7.1 Procedures for PVR Service Capture Request 

The SIP MESSAGE method is used here to achieve what is described in the architectural document (TS 182 027 [2]) as 
"PVR content capture request". This request may be done in an impulsive way or offline. 

5.1 .7.1 .1 Procedures for Impulsive Request 

This use case is itself divided in two sub-cases: 

Case 1: The user does not specify any end date and time for the recording. This can be seen as a case of "Park 
and pickup TV" as described in TS 182 027 [2]: 

In this case the UE shall send a SIP MESSAGE request to SCF requiring Bookmark setting. The contents of the SIP 
MESSAGE request shall be as follows: 

• The Request-URI in the MESSAGE request shall be the well known PSI (Public Service Identifier) of the BC 

Service. 

NOTE 1: This is the same value as the Request-URI for BC service session initiation. 

• From and To headers shall be set to the pubUc identity of the user issuing the MESSAGE message. 

• Call-ID shall be generated by UE. 

• CSeq shall be generated by UE. 

• The Content-type header shall include the registered MIME type of XML documents representing IPTV 
service action data: "application/vnd.etsi.iptvcommand+xml". 

• The message body carries the service action data: the matching "BC Bookmarks" object shall be created so 
that: 

IPTVActionDataConomand shall be set to "Record" . 
Record shall be set to "IPTVBc ActionData" . 
BCServiceld is set to the value of the current channel. 
Programmeld is optionally set to the value of the current programme. 

Bookmark is set to the current timestamp if the UE has the knowledge of such timestamp (e.g. through 
SNTP). If the UE is not aware of such current timestamp. Bookmark is set to a default value: "NOW" 
which impUes that the content capture is initiated as soon as the N-PVR SCF gets the request. 

NOTE 2: BookmarkExpiryTime may be updated in two ways. It can be updated according to the user preference 
pre-set by the user, or according to the service policy defined by the service provider. 
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Case 2: The user specifies an end date and time for the recording: 

In this case the UE shall send a MESSAGE request to the SCF. The contents of the SIP MESSAGE request shall be as 
follows: 

• The user-part value of the Request-URI shall be set to the BC Service Package ID that the BC service to be 
recorded belongs to. 

• From and To headers shall be set to the pubUc identity of the user issuing the MESSAGE message. 

• Call-ID shall be generated by UE. 

• CSeq shall be generated by UE. 

• The Content-type header shall include the registered MIME type of XML documents representing IPTV 
service action data: "application/vnd.etsi.iptvcommand-nxml". 

• For N-PVR, the message body carries the service action data: the matching "NPVR item" object shall be 
created so that: 

IPTVActionDataCommand shall be set to "Record" ; 

Record shall be set to "IPTVNpvrActionData" ; 

NPVRContentId is not set; 

BCServiceld is set to the BC Service to be recorded; 

RecordStartDate is set to the current timestamp if the UE has the knowledge of such timestamp 
(e.g. thanks to SNTP). If the UE is not aware of such current timestamp, RecordStartDate should be set 
to a default value: "NOW" which implies that the content capture is started as soon as the NPVR SCF 
gets the request; 

RecordEndDate is set to the end date/time when the recording should stop and would correspond to what 
the user has specified. 

NOTE 3: NPVRContentExpiryTime may be updated in two ways. It can be updated according to the user 
preference pre-set by the user, or according to the service policy defined by the service provider. 

• For C-PVR, the message body carries the service action data: the matching "CPVR item" object shall be 
created so that: 



IPTVActionDataConunand shall be set to "Record"; 
Record shall be set to "IPTVCpvrActionData"; 
CPVRContentId is not set; 

TargetUEId shall be set to the public GRUU or SIP instance ID instead of GRUU; 
BCServiceld is set to the BC Service to be recorded; 

RecordStartDate is set to the current timestamp if the UE has the knowledge of such timestamp 
(e.g. thanks to SNTP). If the UE is not aware of such current timestamp, RecordStartDate should be set 
to a default value: "NOW" which implies that the content capture is started as soon as the PVR SCF gets 
the request; 

RecordEndDate is set to the end date/time when the recording should stop and would correspond to what 
the user has specified. 
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5.1 .7.1 .2 Procedures for Offline Request 

A user may request to record a live programme that has not started yet. In this case the UE shall send a SIP MESSAGE 
request to the SCF. The content of the SIP MESSAGE request shall be as follows: 

• The user-part of the Request-URI shall be set to the BC Service Package ID that the BC service belongs to. 

• From and To headers shall be set to the public identity of the user issuing the MESSAGE message. 

• CSeq shall be generated by UE. 

• The Content-type header shall include the registered MIME type of XML documents representing IPTV 
service action data: "application/vnd.etsi.iptvcommand+xml". 

• For N-PVR, the message body carries the service action data: the matching "NPVR item" object shall be 
created so that: 

IPTVActionDataConomand shall be set to "Record" . 

Record shall be set to "IPTVNpvrActionData" . 

If the recording is requested on a specific entry in the EPG: 

■ NPVRContentld is set to the matching Programmeld. 
If the recording do not match a specific entry in the EPG: 

NPVRContentld is not set. 

■ BCServiceld is set to the BC Service to be recorded. 

■ RecordStartDate is set to the date/time when the recording has to start as specified by the user. 

■ RecordEndDate is set to the date/time when the recording has to be terminated and is specified by 
the user. 

NOTE: NPVRContentExpiryTime may be updated in two ways. It can be updated according to the user 
preference pre-set by the user, or according to the service policy defined by the service provider. 

• For C-PVR, the message body carries the service action data: the matching "CPVR item" object shall be 
created so that: 

IPTVActionDataCommand shall be set to "Record"; 

Record shall be set to "IPTVCpvrActionData"; 

If the recording is requested on a specific entry in the EPG: 

■ CPVRContentId can be set to the matching Programmeld. 
If the recording do not match a specific entry in the EPG: 

CPVRContentId is not set. 

TargetUEId shall be set to the public GRUU to the SIP instance ID instead of GRUU. 

■ BCServiceld is set to the BC Service to be recorded. 

■ RecordStartDate is set to the date/time when the recording has to start as specified by the user. 

■ RecordEndDate is set to the date/time when the recording has to be terminated and is specified by 
the user. 

5.1.7.2 Procedures for N-PVR Session 

The UE follows procedures outlined in clause 5.1.4 for COD to stream a previously captured N-PVR content. 
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The user part of the "Request-URI" parameter shall contain the NPVRContentId retrieved from the SSF as defined in 
clause 6.1.1.5 and shall correspond to the content that was captured via impulsive or offline request. 

The UE shall build the SDP offer as defined in clause 5.1.4.2 for CoD session initiation and shall include media control 
line for RTSP control channel. The SDP offer for the media delivery lines shall specify the transport and codec 
parameters for the corresponding BC Serviceld. 

5.1 .7.3 Procedures for C-PVR Recording Session 

The UE shall then extract the parameters from the received MESSAGE message body and verify the 
"NotificationReason" is "CPVRRecord". The UE extracts further sub-elements message body of the 
"CPVRRecordlnfo" element, as follows: 

• The "CPVRContentID" element in the message body indicates the identifier of the C-PVR content, may be 
used as an index for user. 

• The "BCServiceld" element in the message body indicates the BC service that required to be recorded, UE 
shall initiate a C-PVR recording session which is similar to the procedmes described in clause 5.1.3.1 to join 
the BCServiceld immediately and record the media content. The UE shall correlate the "BCServiceld" with the 
one from the service selection. 

• The "RecordEndDate" element in the message body indicates the BC service that required to be recorded, UE 
shall initiate the end date (and time) of the recording, the UE shall set a timer to terminate the C-PVR 
recording session. 

5.1 .8 Procedure for UGC Service 
5.1 .8.1 Procedure for UGC declaration 

In the case of procedure for declaring user generated content, the UE shall send a SIP MESSAGE request to SCF for 
retrieving UGC contentlD. The contents of the SIP MESSAGE request shall be as follows: 

• The Request-URI in the MESSAGE request shall be the well known PSI (PubUc Service Identifier) of the 
UGC Service. 

• From and To headers shall be set to the public identity of the user issuing the MESSAGE request. 

• Call-ID shall be generated by UE. 

• CSeq shall be generated by UE. 

• The Content-type header shall include the MIME type of XML documents representing IPTV service action 
data: " application/vnd . etsi. iptvsad-ugc+xml" . 

• The message body of MESSAGE request carries the transaction-id, which should match "UGC items" 
specified in annex K. 

The transaction-id is used to identify a UGC declaration transaction, it is a string that is generated and only recognized 

by the UE, and it is carried in the declaration request from the UE and the declaration response from the SCF, and the 
"transaction-id" is not used in the following request response, and the "UGCContentId"can be used to correlate the 
request and response. The transaction-id is unique on the UE and there should be some mechanism for UE to populate 
the unique transaction-id. Time-stamp based transaction-id generation may be seen as an option, which is out of scope 
of current document. 

Upon reception of the MESSAGE request from SCF including UGC contentlD, the UE shall extract UGC contentlD 

and the transaction-id from the message body. A SIP 200 OK response without message body shall be sent back to the 
SCF immediately after the MESSAGE request is successfully received by the UE. 

The UE then uses the transaction-id to correlate the UGC declaration request and enforce the subsequent actions, e.g. 
save the UGC contentlD in local disk. Transaction Id is only valid until the response is received. 
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5.1 .8.2 Procedure for publishing UGC description information by UE 

The procedure is similar to the procedure outhned in clause 5.1.8.1 for declaring user generated content, with the 
following difference: 

• The message body of MESSAGE request carries both the UGC contentID and UGC description information, 
which should match "UGC items" specified in annex K. 

This procedure may be combined with the UGC declaration procedures in clause 5.1.8.1. 

5.1 .8.3 Procedure for UGC creation 
5.1.8.3.1 Session initiation 

The UE shall support the procedures specified in ES 283 003 [20] for originating sessions. 

Upon request for a UGC creation session initiation, the UE shall generate an initial INVITE request as specified in 
ES 283 003 [20] for an originating UE. 

• The "Request-URI" shall be the well known PSI (Public Service Identifier) of the UGC Service. 

• The From header shall indicate the public user identity of the user. 

• The To header shall contain the UGC contentID generated in UGC declaration. 

• Call-ID shall be generated by UE. 

• CSeq shall be generated by UE. 

NOTE 1: The UGC contentID is retrieved from the MESSAGE request sent from SCF in response to the UGC 
declaration request. 

An SDP Offer shall be included in the request. The SDP Offer shall be done in accordance with the media capabilities 
and required bandwidth available for the UGC creating session. 

The SDP Offer at media level shall include the following elements: 

• The "m=" line indicates the type of the media, the transport protocol and the port of the related content 
delivery channel. 

• The "c=" Une shall include the network type with the value set to IN, the address type set to IP4 or IP6 and 
unicast address of the flow of the related content delivery channel, 

(ex . c=IN IP4 <IP_ADDRESS>). 

• The "b=" line shall contain the appropriate bandwidth value that the generating UE supports. Since the UGC 
media stream is unidirectional the bandwidth shall be set to 0, except for the case that the transport is RTSP, 
RTP and RTCP is allowed. 

• For HTTP upload the transfer type may be indicated in the "fmtp:iptv_http_transfer" type attribute. The values 
that are applicable are "progressive" and "streaming". 

The "progressive" upload is content in the UE that is fuUy available for upload and has no restrictions to 
the rate of upload. 

The "streaming" or HTTP streaming is content in the UE that has a restricted rate of upload, for example 
content that is being recorded. 

Other values may be used with a "x-" extension to indicate other proprietary type of downloads. 

EXAMPLE : a=f mtp : iptv_http transfer- type = <transf er-type>) . 

An "a=" line with a "sendonly" attribute 
(ex. a=sendonly). 
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NOTE 2: Procedures for publishing UGC description in clause 5.1.8.1 and UGC declaration procedures in 
clause 5.1.8.2 may also be embedded in the above UGC creation procedures. 

The UE may use the bandwidth and if present the transfer-type attributes in the SDP answer from the session initiation 
response to shape the rate of the content upload. 

The transmission of HTTP content upload is a best effort type of transmission. The speed at which content is 
transmitted with HTTP is limited by the available bandwidth. No prioritization is performed on the transmission of 
upload. If differentiation is required for HTTP content upload the attribute "transfer-type" SHALL be supported. 

The inclusion of the attribute "transfer-type" indicates to IMS and local transport policies in RACS that a session with 
special requirements shall be setup. For example HTTP streaming shall be set up with the bandwidth included in the 
SDP is the maximum guaranteed bandwidth for transmission. 

5.1 .8.4 Procedure for UGC watching session 

5.1.8.4.1 UGC selection 

The UE can select UGC content based on several methods: 

• Selection through the SSF, see clause 6.1.1 

• Content recommendation 

• Notification, see clause 5.1.9 

• Pre-selection, see below 

When a UE wants to pre-select UGC content that had already been declared and published but not yet created, it shall 
send a SIP MESSAGE request to the SCF. The contents of the SIP MESSAGE request shall be as follows: 

• The Request-URI shall be the well known PSI (PubUc Service Identifier) of the UGC Service. 

• From and To headers shall be set to the pubUc identity of the user issuing the MESSAGE request. 

• Call-ID shall be generated by UE. 

• CSeq shall be generated by UE. 

• The Content-type header shall include the MIME type of XML documents representing IPTV service action 
data: "appUcation/vnd.etsi.iptvsad-ugc+xml" . 

NOTE: The XML schema corresponding to the MIME type "application/vnd.etsi.iptvsad-ugc+xml" is available in 
annex K of the present document. 

• The message body contains the contentID of the UGC content the UE wants to pre-select 

Upon receiving the SIP 200 OK answer from the SCF the UE stores the contentID of the pre-selected UGC. 

5.1.8.4.2 Session initiation 

UE-initiated: When the UE selects UGC through the SSF, content recommendation, or notification it shiiU perform UE- 
initiated session initiation as described in clause 5.1.4.2 for CoD. 

SCF-initiated: Upon receiving an incoming INVITE the UE shall inspect the From header. If the From header includes 
contentID which corresponds to the stored contented of pre-selected content, the UE shall accept the SCF-initiated 
session initiation as described in clause 5.1.4.2A for CoD. 
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5.1.9 Notification service 

5.1 .9.1 Procedure for Notification service using signalling path 

Upon reception of a SIP MESSAGE request, the UE shall check the Content-type header indicating 
"application/vnd.etsi.iptvnotification+xml" to verify the notification message. The UE shall parse the XML document 
defined in annex S. 

After all elements have been processed, the UE may present the received notification to the user and take the 
appropriate further actions. 

5.1 .10 Procedure for Remote Service Initiation 

5.1 .1 0.1 Procedure for service initiation by remote UE 

When the Remote UE wants to initiate an IPTV service on the Target UE, the Remote UE shall send a SIP REFER 
request to Target UE, and the REFER message is routed to SCF by IFC. The contents of the SIP REFER request shall 
be as follows: 

• The Request-URI in the REFER request shall be set to the public GRUU or to the registered IMPU of the 
Target UE with the Accept-Contact header set to the SIP instance feature tag defined in clause 5.6.3 of the 
Target UE; 

• From header should be set to the pubUc identity of the user issuing the REFER request; 

• To header should be set to the public GRUU or the IMPU of the Target UE; 

• Call-ID shall be generated by the Remote UE; 

• CSeq shall be generated by Remote UE; 

• Refer-To shall include the following parameters: 

the SIP URI should be set to the PSI of the service to be activated on the Target UE; 

the "method" shall be set to appropriate values according to different service, such as "INVITE" for BC, 
Cod; "MESSAGE" for UGC. 

When the Remote UE receive the NOTIFY message, the remote UE should send a SIP 200 OK to the originating UE. 

5.1 .1 0.2 Procedure for service initiation on the Target UE 

When receiving a SIP REFER request, the Target UE shall check whether or not it is capable of initiating the indicated 
IPTV session, e.g. Refer-To header to extract the Request-URI should start service request as the "Refer-To" message 
header of the REFER. 

If the Target UE is capable of initiating the service, the Target UE shall send a SIP 200 OK Message immediately. And 
the SIP 200 OK Message should be the same to the REFER request received before except the "contact" head field: 

• Contact shall be set to the GRUU of the Target UE. 

Then the Target UE should send an immediate NOTIFY message to remote UE for informing the agent sending the 
REFER of the status of the reference which shall be set as follows: 

• From header shall be set to the pubUc GRUU of the Target UE. 

• To header shall be set to pubUc identity of the user issuing the REFER request. 

• Call-ID shall be same to the REFER message received before. 

• CSeq shall be same to the REFER message received before. 

• Content- Type shall be set to "message/sipfrag". 
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• Event shall be set to "refer". 

• Subscription-State shall be set to "active". 

When the Target UE have sent the NOTIFY message, it should initiate the service according to the "Refer-To" message 
header of the REFER. After completion of the service initiation, it should send another NOTIFY message to remote UE, 
and the "Subscription-State" of such NOTIFY message should be set to "terminated" which is different from previous 
NOTIFY message. 

5.1 .11 Procedure for Personalised Service Composition 

5.1.11.1 General 

The Personalised Service Composition (PSC) service composes multiple BC and or CoD sessions into a PSC session. 
The PSCid is used to correlate the different BC/CoD sessions of the PSC, associating these BC/CoD sessions with each 
other within the PSC session, which is identified by the PSCid. 

5.1 .1 1 .2 Generation of the PSCid by the UE 

The UE retrieves available services from SSF and composes a Personalized Service Composition (PSC). The PSC is to 
be composed of multiple BC and/or CoD services. The UE generates a PSCid and makes a record of it. The PSCid 
should be globally unique. 

5.1 .1 1 .3 UE-initiated session initiation 

For all UE-initiated sessions in the PSC, the UE shall include the PSCid in the SDP offer in the initial INVITE request 
to the SCF. 

• An "a=PSCid:<PSCid>" line indicates the PSCid. 
The UE shall correlate the session with the PSCid. 

UE-initiated BC session initiation is specified in clause 5.1.3.1. UE-initiated CoD session initiation is specified in 
clause 5.1.4.2. Other types of IPTV sessions may also be used in a PSC, including an "empty" session that is used only 
to convey the PSCid. 

5.1 .1 1 .4 SCF-inltlated session initiation 

A UE is able to receive an initial invite request from the SCF following the SCF-initiated session initiation procedures 
specified in clauses 5.1.3.1A and 5.1.4.2A. 

When a UE receives an initial INVITE request from the SCF containing a PSCid, it shall check whether it already has a 
record of the indicated PSCid. 

• If it does, then the UE shall correlate the session with the PSCid. 

• If it does not, then the UE shall make a record of the PSCid and correlate the session with the PSCid. 

5. 1 . 11 .5 Session modification 

Sessions within a PSC can be modified using normal session modification procedures, see e.g. clause 5.1.3.2. For UE- 
initiated modification of a session within a PSC, the UE shall include the PSCid in the SIP re-INVITE request or 
UPDATE request, depending on the dialogue state. 

• An "a=PSCid:<PSCid>" line indicates the PSCid 

The value of the PSCid may be different than in the original INVITE request, which indicates that the session is 
transferred to another PSC. The value of the PSCid may also be empty, which indicates that the session is removed 
from the PSC. 
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For an SCF-initiated session modification, the UE shall check the PSCid in the received re-INVITE request or 
UPDATE request. If the PSCid is different from the original PSCid for this session, this indicates that the session is 
transferred to another PSC. If the value of the PSCid is empty, this indicates that the session is removed from the PSC. 

5.1.11.6 Session termination 

Sessions within a PSC are terminated using normal session termination procedures, see e.g. clauses 5.3.1.4 and 5.3.2.4. 
When a session within a PSC is terminated, then the UE shall remove the correlation between that session and the 
PSCid. When the last session within a PSC is terminated, then the UE shall delete the record of the PSCid. 

5.1 .12 Procedure for Personalized Channel (PCh) Service 

5.1 .1 2.1 Procedure for PCh Declaration 

For declaring a Personahzed Channel (PCh), the UE shall send a SIP MESSAGE request to SCF for retrieving PChld. 
The contents of the SIP MESSAGE request shall be as follows: 

• The Request-URI in the MESSAGE request shall be the well known PSI (Pubhc Service Identifier) of the PCh 
Service. 

• From and To headers shall be set to the pubhc identity of the user issuing the MESSAGE request. 

• Call-ID shall be generated by UE. 

• CSeq shall be generated by UE. 

• The Content-type header shall include the MIME type of XML documents representing IPTV service action 
data: "application/vnd.etsi.iptvsad-pch-nxml" (see annex K). 

• The message body carries one "IPTVPChActionData" element which only includes a unique "transaction-id" 
attribute that is generated by the UE. 

• If the UE wants to avoid forking in case the user is registered with the same IMPU from several devices, the 
UE should include the contact header and should include there in a pubUc GRUU, a temporary GRUU or the 
sip instance feature tag. 

The transaction-id is used to identify a declaration transaction. It is a string that is generated and only recognized by the 
UE, and it is carried in the declaration request from the UE and the declaration response from the SCF, and the 
"transaction-id" is not used in the following request response, and the PChID can be used to correlate the request and 
response. The transaction-id is unique on the UE and there should be some mechanisms for UE to populate the unique 
transaction-id. Time-stamp based transaction-id generation may be seen as an option, which is out of scope of current 
document. 

A SIP 200 OK response without message body shall be sent back to the SCF immediately after the MESSAGE request 
is successfully received by the UE. 

Upon reception of the MESSAGE request from SCF including PChId, the UE shall extract PChId from the message 
body. Transaction Id is only vahd until the response is received. 

5. 1 . 1 2.2 Procedure for PCh Operation 
5.1 .1 2.2.1 PCh Session Initiation 

For the PCh MF option, the PCh session initiation is similar with the CoD session initiation as described in clause 
5.1.4.2, with the following differences: 

• The "Request-URI" in the INVITE request shall be set to the PChId generated in PCh declaration procedure. 

• The To header in the INVITE request shall contain the same PChId as in the "Request-URI" parameter. 
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5.1 .12.2.2 Session modification due to a PCIi Content Item Switcli 

Upon receipt of a re-INVITE request or an UPDATE request, the UE shall modify the session as specified in procedure 
for CoD service of clause 5.1.4. 

5.1 .1 2.2.3 PCIi Overlap Handling through User interaction 

On reception of SIP INFO request, that includes the PCh-Overlap-Handhng Info Package in accordance with the SIP 
INFO framework, the UE shall examine the Call-ID header and the Content-type header which is 
"application/vnd.etsi.iptvsad-pch-overlapH-xml" to identify the PCh conflict option request. 

The UE extracts the options from the message body, and selects one option according to the user choice and the UE 
capabilities (e.g. capability for C-PVR) . 

Following successful processing of the SIP INFO request, the UE shall send back a SIP 200 OK response to the sender. 

Then the UE shall send another SIP INFO request back to the SCF including the PCh-Overlap-Handhng representing 
the choice result, as follows: 

• The Request-URl, To header, Call-ID shall be set identical to those present in the PCh session initiation 
procedure. 

• The CSeq shall be generated by the UE. 

• The Content-type shall be set to "application/vnd.etsi.iptvsad-pch-overlap-nxml" which representing the PCh 
conflict choice data (see annex U). 

• The message body shall include the selected option that handles the PCh overlap. 

Note that it is assumed that both the UE and the SCF indicated their willingness to receive the PCh-Overlap-Handling 
Info Package. 

5.1 .13 Procedure for Content Insertion at UE Side 

Content insertion at the UE side is a generic capability that allows for inserting content. Content insertion is triggered 
by user input at the UE side or event detection by the UE or SCF. Annex A.6 provides example signalhng flows for the 
case where the SCF detects an event and for the case where a user pauses a CoD stream. 

For the purpose of content insertion, the UE shall recieve a SIP INFO request including the Event-Notification Info 
Package (defined in clause ZA.4) according to the SIP INFO framework with Content-type set to 
"apphcation/vnd.etsi.iptvnotification-Hxml". 

The UE shall then extract the parameters from the body in the received SIP INFO request and varify the 
"NotificationReason" is "Contentlnsertion". 

Following successful processing of the SIP INFO request, the UE shall send back a SIP 200 OK response to the sender. 

The UE checks the local device for the support of content insertion and extracts further sub-elements message body of 
the "Contentlnsertionlnfo" element, as follows: 

• The "ContentlnsertionReason" element in the message body describes the reason for Contentlnsertion. The 
currentiy specified types are "Advertising", "PausedContent", "Generic". 

NOTE 1 : The UE can handle the content insertion appropriately based on the reason for the insertion. The decision 
logic, as well as any configuration by the network, is operator-dependent and out of scope of the present 
document. Additionally, the UE may reject the insertion based on criteria such as local resource 
availability, bandwidth availability etc. 
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• The "ContentlnsertionTiine" element contains two sub-elements: 

The "ContentlnsertionStartTime" element in the message body indicates the content start time. If it is 
earlier than the present clock, the UE shall ignore the SIP INFO request as if it is sent in error. If it is 
later than the present clock, the UE shall set up a timer to wait for the triggering of content insertion 
handling. If the body does not carry a "ContentlnsertionStartTime" element, or the timer for the content 
insertion triggering is up, the UE shall perform the content insertion immediately: 

The "ContentlnsertionDuration" element in the message body indicates the duration of content insertion. 

• If the message body carries a PSCid according to clause 5.1.11, the PSCid is associated with the ongoing 
BC/CoD session and it is used to associate this session with the new session for content insertion. 

• If the message body carries a "MulticastContent" element, the UE shall initiate an INVITE request as 
described in clause 5.1.3.1, where the first BCServicelD that the UE tends to join shall be set to the one 
extracted from the "MulticastContent" element: 

The SDP offer includes the PSCid according to clause 5.1.1 1.3 if available. This results in a PSC session 
composed of the ongoing BC/CoD session and the new multicast session for content insertion. 

• If the message body carries a "UnicastContent" element, the UE shall initiate an INVITE request as described 
in clause 5.1.4.2, where the Request-URI in the request shall include the one extracted from the 
"UnicastContent" element: 

The SDP offer includes the PSCid according to clause 5.1.11.3 if available. This results in a PSC session 
composed of the ongoing BC/CoD session and the new unicast session for content insertion. 

NOTE 2: Since the PSCid is known by both the UE and the SCF, it allows for specific UE and/or network 

behaviour in case of associated sessions within a Personalized Service Composition. For example in case 
of advertisement the inserted content has reduced trick-play capabilities, or for example the SCF may pre- 
reserve and allocate sufficent additional bandwidth for the new content insertion session. 

• The SIP INVITE request initiated by the UE shall be constructed according to the procedures for BC service in 
clause 5.1.3 for multicast content insertion and the procedures for CoD service in clause 5.1.4 for unicast 

content insertion. 

After the new session has been established, the UE may use SIP INFO to update the content insertion SAD information. 
For example, in the cases when the content insertion is rejected, or has begun, ended, failed etc, the UE shall send SIP 
INFO to the SCF reporting the insertion status, with the InsertionStatus element set to "Rejected", "Started", "Finished" 
and "Failed" respectively. The Service Action Data information (see annex K) shall be populated as follows: 

• IPT VActionDataConamand shall be set to "Notify" . 

• Notify shall be set to "IPTVContentlnsertionActionData" . 

• "IPTVContentldentifer" shall be set to the content identifier of on-going session, e.g. the BC service id, the 
CoD content identifier etc. 

• "InsertedContentldentifer" shall be set to the content identifier of the content that is inserted to the on-going 

session. 

• The "InsertionStatus" element shall be present and set to "Accepted". 

The Content-Type Header of the SIP INFO message shall be set to "appUcation/vnd.etsi.iptvcommand+xml". 
Note that the UE must have indicated its willingness to receive the Event-Notification Info Package. 

5.1 .14 Procedures for IPTV Content Marker Service 
5.1 .14.1 Procedure for IPTV Content Marker handling 

The IPTV Content Marker handling procedure applies to storing, updating and removing IPTV Content Markers. 
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For storing and/or updating the IPTV Content Marker, the UE shall, within an existing SIP dialog with the SCF, send a 
SIP INFO request that includes the IPTV-Content-Marker Info Package (defined in clause ZA.3) according to the SIP 
INFO framework, or send a SIP MESSAGE request to the SCF if there is no ongoing SIP dialog with the SCF. The 
contents of the SIP INFO/SIP MESSAGE request shall be as follows: 

• The value of the Request-URI shall be set to the one used in the related session, where applicable. 

• From and To headers shall be set to the one defined during the session initiation procedure. 

• Call-ID shall be set to the same value as that of the CoD session. 

• CSeq shall be generated by the UE following rules defined in ES 283 003 [20] for request within a dialog. 

The Content-type header shall include the registered MIME type of XML documents representing IPTV Content 
Marker data: "application/vnd.etsi.iptvcontentmarker+xml". 

The message body carries data of IPTV Content Marker. The content of SIP INFO/SIP MESSAGE request shall be 
follows: 

IPTVInformationDataCommand shall be set to "Update". 

IPTVContentMarkerlD is not set when the user wants to register IPTV Content Marker. If the user wants 
to update IPTV Content Marker data, IPTVContentMarkerlD shall be set the value of targeted IPTV 
Content Marker. 

OwnerUserlD shall be set to IMPU. 

IPTV service type identifier shall be set to the value of IPTV service type this IPTV Content Marker 
refers When the user updates IPTV Content Marker data, this value should not be changed. 

IPTV content identifier shall be set to the value of IPTV content identifier. When the user updates IPTV 
Content Marker data, this value should not be changed. 

Forbidden Vie wUser is optionally set to IMPUs of specific users with whom the owner of this IPTV 
Content Marker does not want to share this particular IPTV Content Marker. 

StartTimeOflPTVContentMarker is optionally set to the timestamp value the UE indicates. 

EndTimeOflPTVContentMarker is optionally set to the timestamp value the UE indicates. 

UserComment is optionally set to string value of comment the user notes. 

GenerationTime is optinally set to the timestamp value of creating IPTV Content Marker. This value is 
generated by the SCF. 

Expiry Time is optionally set to the timestamp value IPTV Content Marker expires. To delete an existing 
IPTV Content Marker, the UE shall set this value to -1. 

Tag: Represents any categorization chosen by the user. 

Rank: Represents the user favorite rating for the content marker. 

Retrieval count: SHALL be set to and incremented by the service provider when the content marker is 
retrieved. This value is set by the SCF. 

Retrieval Time SHALL be updated with a new entry every time the content bookmark is retrieved (note 
that retrieval does not imply the content bookmark is used). This value is set by the SCF. 

Updating and removing of content markers may also occur outside an existing session and if so than XCAP should be 
used for that purpose if the information is stored in the user profile. 

NOTE: Ranking and tagging procedures are considered out of scope (as UE intern procedures). 



ETSI 



57 



ETSI TS 183 063 V3.5.1 (2011-02) 



5.1 .15 Procedure for Targeted Ad Insertion (TAI) 

5.1.15.1 TAI at UE side 

In the case when service state detection happens at the SCF as described in clause 5.3.14.1, the UE shall use procedure 
for content insertion at UE side described in clauses 5.1.13 for TAI at UE side. 

The following attributes in the content insertion data are used as following: 

• The "ContentlnsertionStartTime" indicates the ad insertion start time, the handling of the processing of 
"ContentlnsertionStartTime" is same with the handling of the content insertion. 

• The "ContentlnsertionEndTime" element indicates the ad insertion end time. 

• The "MulticastContent " element, it indicates multicast ad insertion, and the "UnicastAd" element indicates 
unicast AD insertion, the UE shall initiate an INVITE request according to the handling of content. 

The response of the request and the following session initiation of the inserted ad is the same with the procedures 
described in the content insertion procedures. 

5.1.15.2 TAI at MF side 

NOTE: There are no additional procedures needed for the TAI at MF side. 

5.1 .16 Procedures for Content Switch within a CoD Contentlist(User- 
Owned) 

CoD content lists are lists.that are typically owned by a user and are under user control when it comes to content 
switching. The assumption in this case, is that all of the contents within one CoD contentUst shall share the same 
content delivery description information (e.g. the same QoS requirement), so that session modification procedures are 
not needed when users switch content within the contentUst. Note that the user is able to perform trickmodes on any 
content in the list. 

5.1 .1 6.1 UE-initiated session Session initiation 

The session initiation is similar with the CoD session initiation as described in clause 5.1.4.2, with the following 
differences: 

• The "Request-URI" in the INVITE request shall be set to the Content identifier fetched from the service 

discovery procedures. 

• An "a=fmtp:3gpp_rtsp h-Supported" attribute shall be present and set as "3gpp-switch", under the "m" line for 
RTSP stream which is defined in annex A of [51]. 

When the UE receives the SIP 200 OK response from MF, the UE shall examine that an "a=fmtp:3gpp_rtsp h- 
Supported" attribute is present and set as "3gpp-switch" under the "m" line for RTSP stream. The UE then extracts the 
contentlist information from the XML message body and stores it. The UE may present the received contentUst 
information, e.g. "ContentltemName" to the user and take the appropriate fiirther actions. 

NOTE: The MF represents a combination of the MCF & MDF. In this context the MCF functionality is expected 
to be used. 

5.1 .17 Procedures with other IMS Services 

5.1 .1 7.1 Instant Messaging Procedures 

When the UE supports OMA Instant Messaging according to [21] the UE shall follow the following procedures. 
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When UE supports messaging using these procedures the SIP REGISTER Contact header shall include the OMA 
Instant Messaging feature tag '+g.oma.sip-im' according to [50] and an IPTV IMS Application Reference Identifier 
(lARI) URN media feature tag "um:um-xxx:3gpp-appIication.ims.iari.iptv-application" according to [21]. Example of 
the feature tag: 

g. 3gpp . iari-ref="urn%3Aurn-xxx%3A3gpp- application. ims . iari . iptv- application" 

Upon reception of a SIP MESSAGE with an Accept-Contact header with Instant Messaging feature tag '+g.oma.sip-im' 
and IARI media feature tag 'urn:urn-xxx:3gpp-application.ims.iari.iptv-application' the UE shall handle the body as an 
IPTV related IPTV message. This allows the UE to screen regular SIP MESSAGE not coming from the SCF, e.g. in 
order to exhibit IPTV-specific behaviour. 

The body may include information relating to IPTV (for example TV program reminder/subscription set by the user). 

NOTE: If information related to IPTV is included in the message, this mechanism serves as an alternative to the 
procedure in clause 5.3.6; it is intended to be used if different types of IMS devices are targeted, among 
which non-lPTV devices. 

Upon successful reception of the request the UE responds with a SIP 200 OK response. 

5.1 .18 Procedures for Unicast Content Download 

5.1 .18.1 UE-initiated Content download session initiation for unicast download 

The UE shall support the procedures specified in ES 283 003 [20] for originating sessions. 

Upon a request for a content download session initiation, the UE shall generate an initial INVITE request as specified in 
ES 283 003 [20] for an originating UE, and specifically: 

• the Request-URI shall contain the download content URI as CDS XML unicast locator described in TS 102 
034 [3] clause 10.3.2.2; 

• the TO header shall contain the download content URI; 

• the content identifier shall be retrieved from service selection information (see annex L concerning the 
mapping between service selection information and SIP/SDP parameters); 

• the FROM header shall indicate the public user identity of the user; 

• an SDP Offer shall be included in the request. The SDP Offer shall be done in accordance with the media 
capabiUties and required bandwidth available for the content download session; 

• the SDP Offer at media level shall include the following elements: 

an "m" line for an HTTP download of format: m=<media> <port> <transport> <fmt>: 

■ the media field shall have a value of "application" ; 

■ the port field shall be set to a value of 9, which is the discard port; 

■ the transport field shall be set to TCP; 

■ the fmt parameter shall be included and shall be set to iptv_http 
(ex. m=application 9 tcp iptv_http). 

an "a=setup" attribute shall be present and set to "active" as defined in ES 283 003 [20] 
(ex. a=setup : active); 

an "a= connection" attribute shall be present and set as "new" as defined in ES 283 003 [20] 
(ex. a=connection : new); 

a "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP 
address of the flow of the related HTTP channel 
(ex. c=IN IP4 <IP_ADDRESS>) ; 
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optionally, the "b=" line may contain the proposed bandwidth. If the user has fetched the bandwidth 
required for this particular content delivery channel during service selection procedure, the bandwidth 
attribute at media level shall be set to this value 
(ex. b=AS:15000); 

the type of content download may be indicated in the "fmtp:iptv_http transfer- type" attribute. The values 
that are applicable are "progressive" and "streaming": 

The "progressive" download is content that is viewed as download is stored or buffered in the UE. 

■ The "streaming" or HTTP streaming is content that is viewed without storing or very limited 
buffering in the UE similar to RTSP streaming. 

Other values may be used with a "x-" extension to indicated other proprietary type of downloads, 
(ex. a=f mtp : iptv_http transfer-type = <transfer-type>). 

The transmission of HTTP content download is a best effort type of transmission. The speed at which content is 
transmitted with HTTP is limited by the available bandwidth. No prioritization is performed on the transmission of 
download. If differentiation is required for HTTP download the attribute "transfer- type" SHALL be supported. 

The inclusion of the attribute "transfer-type" indicates to IMS and local transport policies in RACS that a session with 
special requirements shall be setup. For example HTTP streaming shall be set up with the bandwidth included in the 
SDP is the maximum guaranteed bandwidth for transmission. 

5.1 .18.2 UE-initiated Content download session initiation for multicast download 

NOTE: The details about acquiring and initiating multicast download have to be contributed and are not specified 
in this release The procedures need to conform to CDS in TS 102 034 [3] and will be similar to the 
procedures for unicast download (clause 5.1.18.1) and will be contributed for this clause. 

5.1 .19 Procedure for Preview Service 

5.1 .1 9.1 Procedures for BC preview session 
5.1.19.1.1 Session initiation 

The BC content preview procedures may take place in the following cases: 

1) Single-screen BC preview: Preview a specific BC program before the users decide to pay for it. 

2) Multi-screen BC preview: Preview the BC services where the preview content is provided through a multi- 
screen mode (e.g. PiP, Mosaic). 

The BC preview session initiation shall use the BC session initiation procedures described in clause 5.1.3.1. The use of 
single-screen and/or multi-screen BC preview is independent of number of sessions and m-lines that are required. The 
UE can either establish a single BC session with the SDP carrying multiple m-line(s) including all the BC service 
identifiers of the BC channels that the UE intends to preview, or the UE can initiate independent sessions for each BC 
channel that the UE intends to preview. 

NOTE: For the BC preview service, regular BC content and preview BC content can use different BC service 
identifiers. 

5.1 .1 9.2 Procedures for CoD preview session 
5.1.19.2.1 Session initiation 

For preview content having its own content identifier, the preview procedures refer to procedures specified in clause 
5.1.4.2. 

When the UE intends to terminate the CoD session, the procedure in clause 5.1.4.4 can be used. 
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5.1 .20 Procedure for Session Transfer 

5.1.20.1 Generic Procedure 

These procedures are generic to all session transfer modes. For all modes the transferee UE initiates the new session 
that replaces the transferred session. 

5.1 .20.1 .1 Transferee UE session initiation 

The transferee UE shall generate an initial INVITE using the same procedure in clause 5.1.4.2 with the following 
qualifications: 

• A new SIP header Replace header is included and is set to the information retrieved from the incoming 
REFER as per clause 5.1.20.2.3 Transferee UE Handling for Incoming Session Transfer Request. 

• For the push mode of session transfer, the domain part in the "Request-URI" is set to the field extracted from 
the To header embedded in the Refer-To header in the incoming REFER received by the transferee UE. 

• Finally, the SDP composition is based on the information extracted from the body header in the Refer-To 
header in the incoming SIP REFER. 

5.1 .20.2 Session Transfer - Push Mode 

5.1 .20.2.1 Transferor UE Locating a Transferee 

To identify a transferee UE for a session, the transferor shall subscribe to the Registration-event package for the public 
user identity of the user as specified in ES 283 003 [20]. The transferor UE shall then locate an appropriate UE from the 
returned information and initiate a session transfer request to it according to clause 5.1.20.2.2. 

5.1 .20.2.2 Transferor UE Initiation of Session Transfer Request 

The transferor UE shall generate a REFER request to the transferee UE identified in clause 5.1.20.2.1. The transferor 
UE shall follow the procedures in TS 124 237 [58], clause 15 entitled "15 Roles for inter-UE transfer without 
estabhshment of collaborative session". 

In particular, the Request URI in the REFER request shall be set to the target device contact information derived from 
information returned in clause 5.1.20.2.1. The tranferor shall include in the contact header field a pubhc GRUU or a 
temporary GRUU. 

The Refer-To header in the REFER request shall be set to the remote target URI included in the contact header field 
returned in the SIP 200 OK associated with initial session CoD setup by the transferor. Additionally, the Refer-To shall 
be extended with the following URI headers fields: 

• Replaces header field SHALL include the SIP dialog identifier for the original CoD session as per 
RFC 3891 [70]. 

• Require header field populated with the option tag value "replaces". 

• To header field includes the original content identifier copied ftom the Request URI of the original SIP 
INVITE request initiated from the transferor. 

• Optionally an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag set to the IPTV 
Communication service identifier "um%3Aum-7%3A3gpp-service.ims.icsi.iptv". 

• P-preferred-Service set to IPTV Communication service Identifier urn:urn-7:3gpp-service.ims.icsi.iptv. 

• Body header. This contains the SDP body to be included in the CoD request initiated from the transferee UE. 
The SDP body shall contain the same number of media Unes as the SDP used in the original CoD session from 
the transferor UE. Each media line shall indicate the same media type as its corresponding media component 
in the SDP used in the original session by the transferor UE. 

The body of the REFER request shall include the IPTV Content Marker for the original CoD session. 



ETSI 



61 ETSI TS 1 83 063 V3.5.1 (201 1 -02) 

Upon receipt of a SIP 200 OK, the transferor UE shall wait for the outcome of the transfer request. 

Upon receipt of a SIP UPDATE or SIP re-INVITE on the old session, instructing the UE that the media is on hold (port 
set to 0), the transferor shall abstain for performing any RTSP transactions on the old session. 

Upon receipt of a SIP NOTIFY request, indicating the success of the session transfer request, the transferor UE returns 
a SIP 200 OK final response. 

The transferor UE shall receive a SIP BYE request to terminate the CoD session to which the transferor UE returns a 
SIP 200 OK. This completes the successful transfer of the session. 

5.1 .20.2.3 Transferee UE Handling for Incoming Session Transfer Request 

Upon receipt by a UE for a SIP REFER request that indicates a session transfer, and if the transferee UE accepts the 
incoming SIP REFER, after validating the SIP REFER request, a SIP 200 OK request is returned as a response. 

The transferee UE extracts the following information from the incoming SIP REFER request: 

• The Content URI extracted from the To header included in the Refer-To header. 

• The body header to use as the SDP for initiating a session. 

• The Dialog ID to be replaced, extracted from the Replace header, in the Refer-To header. 

• The IPTV Content Marker from the SIP REFER body. 

Subsequently, the transferee UE initiates a new CoD session as per clause 5.1.20.2.1. 

Once the session is successfully established, the transferee initiates a SIP NOTIFY towards the transferor UE. 

Upon receipt of SIP 200 OK response, the transferee UE stores the relevant information and is now ready to start trick- 
play mode for viewing the content. 

5.2 Service Discovery Function (SDF) 

5.2.1 Procedure for IIVIS registration 

If deUvery of service discovery information using push mode is supported, the SDF acts as a third-party registrar and 
receive REGISTER requests from the Core-IMS during the IMS registration phase. 

The SDF shall store the public user identity of the user as received in the To header and use it to initiate delivery of 
service discovery information in push mode towards this user. The SDF shall answer to the REGISTER request with a 
SIP 200 OK response as specified in ES 283 003 |20|. 

If dehvery of service discovery information in push mode is not used, the SDF shall send a 501 error response to the 
Core-IMS. 

5.2.2 Procedure for service attachment 
5.2.2.1 Push mode 

In the push mode, after the regular third-party registration, the SDF shall generate a SIP MESSAGE to the UE, and the 
service attachment information is taken in the message body of the SIP MESSAGE. 

The SDF uses the SIP MESSAGE to transport the service attachment information, and the SDF shall generate a SIP 
MESSAGE request in accordance with ES 283 003 [20] and TS 124 229 [24] as used in ES 283 003 [20]. 
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The contents of the SIP method request shall be as follows: 

• The Request-URI of the SIP MESSAGE request shall be set to the public user identity of the intended 
recipient. 

• The From head shall be set to the SIP URI of the SDF. 

• The To head shall be set to the pubhc user identity of the intended recipient. 

• The content type shall be set to "application/vnd.etsi.iptvdiscovery+xml". 

• The message body shall conform to the XML schema described in annex M and shall be according to 
clause 5.2.2.3. 

The SDF shall send the SIP MESSAGE request towards the Core IMS according to the procedures of the Core IMS. 

When the SDF generates and sends the service attachment information to the UE, it can check IPTV profile of the user, 
and provides the custom/personahze service attachment information to the UE. IPTV profile including: 

• Location information, e.g. the SDF can retrieve the location of the UE and send the address of the SSF based 
on the location of the UE. 

• User subscription information. 

• UE capabiUties, including the model, vender, version, coding format etc., and the SDF can send the service 
attachment information to the UE based the UE capabilities. When the service attachment information is 
changed, the SDF may generate a SIP method request including new service attachment information. 

5.2.2.2 Pull mode 

The SDF addresses may be determined by the UE using any of the alternatives as defined in annex I. 

When the SDF receives a SUBSCRIBE request, if personalized information is required it shall perform user's identity 
verification as defined in ES 283 003 [201, clause 5.7.1.4. After successful user identification if an IPTV User Profile is 
available it is possible to perform personalization of the body (Service Attachment Information) of the NOTIFY. 
Filtering may also be performed if device capabilities are available to the SDF. 

If the SDF receives a SIP SUBSCRIBE message body from the UE carrying UE capabilities, the SDF shall process the 
SIP request as follows - if the content-type in the request does not match "application/vnd.etsi.iptvueprofile+xml:, then 
the SDF shall respond with a 415 Unsupported Media Type error. 

The SDF shall examine the parameters specified in the SIP SUBSCRIBE body and shall then record UE capabihties 
information as part of the IPTV user profile data. 

NOTE 1 : The UE capabilities that are recorded as part of the IPTV user profile may be used by the SSF for 
personalization purposes. 

For a successful subscription, the SDF shall generate a SIP 200 OK in response to the SUBSCRIBE request. The SDF 
shall then send a NOTIFY request immediately. 

NOTE 2: The SDF can select personalized SSF information based on IPTV user profile. For example, the SDF will 
send only addresses of SSF(s) that contain information (e.g. EPG) related to the BC service package(s) 
subscribed by the user. 

The contents of the NOTIFY request shall be as follows: 

The Event header shall be set to the "ua-profile" event package. 

The "effective-by" parameter for the event header shall be set to 0. 

The content type shall be set to "application/vnd.etsi.iptvdiscovery-nxml". 

The message body shall conform to the XML schema described in annex M and shall be according to 
clause 5.2.2.3. 
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SUBSCRIBE request 
received by the SDF 



No 





Figure 5.2.2.2: SDF logic for processing SUBSCRIBE requests 



When any parameter of service configuration information has changed, the SDF may generate a NOTIFY request 
including new service configuration information. 
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5.2.2.3 Service Attachment Information 

The body of the SIP message from SDF shall include an XML document as defined in annex M listing SSF addresses 
and the means of connecting to the SSFs for retrieving service selection information. 

For each SSF, the following sub-elements are populated as follows: 



Table 5.2.2.3: SSF information sending by SDF during service attacliment procedure 



Element Name 


Description 


iUlandatory(l\1)/ 
Optionai (0) 


Many = severai 
instances are 
possible 


SSF 


Root element 


M 


Many 


@ID 


Identifier for SSF defined uniquely for a given 
SDF 


M 




©Technology 


Indicates the technology used for delivering 
service selection information. Currently defined 
technologies are 

"dvb.org_iptv""openmobilealliance.org_bcast", 

"tispan.org sad", "tispan.org_tva2", and 

"tispan.org_iptvcontentmarl<er". 

Refer to annex L for the mapping of Technologies 

defined in the present document 

Refer to annex for the definition procedure of 

new technologies 


M 




©Version 


This is incremented when one or more fields in 
SSF element have changed 






Description 


Description of the SSF for potential display in one 
or more languages. One description is allowed 

per language 





Many 


ServiceProvider 


Provides information about IPTV service provider 







@DomainName 


The IPTV service provider domain name 


M 




@LogoURI 


Link for the IPTV Service Provider Logo 







Name 


Name of the IPTV Service Provider for potential 
display in one or more languages. One name is 
allowed per language 


M 


Many 


Description 


Description of the IPTV Service Provider for 
potential display in one or more languages. One 
description is allowed per language 





Many 
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Element Name 


Description 


Ivlandatory(M)/ 
Optional (0) 


lUlany = several 
instances are 
possible 


Pull 


Provide information to access SSF via Pull Mode 





Many 


©Location 


URI of tfie SSF 


M 




DataType 


Specifies the type of service selection information 
available at the SSF (e.g. COD, BC) 


M 


Many 


@Type 


The type of service selection information. The 
exact format is determined by the Technology 


M 




Segment 


Used to logically separate service selection 
information 


The 

mandatory/optional 
nature of this 
parameter depends 
on the SSF 
Technology and is 
detailed in annex L 




@ID 


Identifier for segment. The exact format is 
determined by the Technology 


M 




©Version 


This is incremented when the information in 

segment changes 







Push 


Provide information to access SSF via Push 
IVlode 





Many 


@IPVerslon 


Specifies the IP Version (4 or 6). If omitted, then 
version 4 is assumed 







@MultlcastAddress 


The address to join to in order to retrieve service 
selection data 


M 




@MultlcastAddress 


The address to join to in order to retrieve service 
selection data 


M 




@SourceAddress 


The address of the sender of the service 

selection data 







DataType 


Specifies the type of service selection information 
available at the SSF (e.g. COD, BC) 


M 


Many 


@Type 


The type of service selection information. The 
exact format is determined by the Technology 


M 




Segment 


Used to logically separate service selection 
information 


The 

mandatory/optional 
nature of this 
parameter depends 
on the SSF 
Technology and is 
detailed in annex L 




@ID 


Identifier for segment. The exact format is 
determined by the Technology 


M 




@Verslon 


This is incremented when the information in 
segment changes 








NOTE 1: The mechanism used by the SDF to gather SSF information belonging to multiple service providers is 
outside the scope of Release 3. 

The following constraints apply to XML documents as described by table 5.2.2.3: 

• There shall be at least one Pull or Push element specified for an SSF. 

• When an optional element is included in the XML document, then all mandatory attributes and sub-elements 
related to this element shall be included as well. 

• Extensions to the elements are possible (refer to the XML schema deiined in annex M). 

NOTE 2: Alternatively, annex J describes the optional case, when using a non-SIP AS based SDF (e.g. for legacy 
purpose) as described in annex A of TS 182 027 [2]. 
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5.3 Service Control Function (SCF) 

5.3.1 Procedure for BC service 
5.3.1 .1 UE-initiated session initiation 

The SCF shall support the procedures specified in ES 283 003 [20] apphcable to an AS acting as a terminating UA. 

Upon receipt of SIP INVITE request, the SCF shall examine the Request-URI to determine that it is a BC session 
initiation request. According to the user subscription information, the SCF shall check the service rights of requested 
broadcast service packages and multicast addresses. If the SCF supports the SIP INFO framework, it shall look for the 
Recv-Info header. 

If the header is present then the SCF shall be able to control the reporting the selected channel. 
If the header is absent, then the SCF shall not be able to control reporting of the selected channel. 
Following that, the SCF shall examine the SDP parameters. In particular: 

• It shall examine the a=bc_service parameter. This parameter contains the channel the UE intends to join. If the 
bc_service parameter does not point to a channel that the UE is allowed to join the SCF shall not accept the 
offer and shall answer with a 403 error code. 

• If present it shall examine the a=bc_service_package attributes and verify that the referred service packages 
are allowed in the user profile. The SCF shall limit the service packages and the BC services according to the 
user subscription (see below). If none of the service packages are subscribed, the SCF shall answer with a 
403 error code. 

• It shall examine the c-line(s) to determine that it is a multicast session. It may also check that it corresponds to 
the bc_service parameter. If not, the SCF shall answer with a 403 error code. 

• It shall examine the b parameter if present to verify that it is the largest bandwidth of the BC services the UE 
intends to join. If not, the SCF shall answer with a 403 error code. 

If the SDP parameters are examined successfully, the SCF shall answer with a SIP 200 OK, indicating the SDP answer 
as follows: 

• The c-lines and m-Unes shall be identical to ones indicated in the SDP offer. 

• It shall include an a=recvonly attribute. 

• It shall include a b-line parameter with the same value as in the offer, if present. If the b-hnes were not present 
in the offer, the SCF shall include one with a value set to the largest bandwidth of all the BC services 
contained in the indicated service packages attribute. 

• If the SDP offer includes one or more a=bc_service_package attribute the SDP answer shall include the same 
number of attributes or less. The SCF shall remove service packages not subscribed by the user. If no 
bc_service_package attributes are included in the SDP offer the SCF shall include in the SDP answer one or 
more a=bc_service_package attribute, except if the SCF knows that the RACS is pre-provisioned with the hst 
of subscribed channels and if all the subscribed channels are allowed for the session. In that case, the inclusion 
of a=bc_service_package is optional. 

NOTE: How the resources are pre-provisioned is a deployment issue; these attributes may be included for 

updating dynamically the RACS with new service packages or multicast address, when the UE knows its 
profile. 

The service packages shall be populated according to the user profile to indicate the service packages and BC services 
that can be used for the session according to annex N. 

If a=bc_service_package attribute is included the SCF shall include one or more mult_list parameter(s) if the user has 
not subscribed to the entire service package. It may also include the bc_service_id_list containing the Ust of subscribed 
BC service ids. If the user has subscribed to the entire service package, the inclusion of mult_list parameter is optionid 
(e.g. depending on SCF local pohcies). 
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Finally, if the UE supports the SIP INFO framework, and if the SCF, as well, supports the SIP INFO frameowork, then 
the SCF shall include the Recv-Info header in the SIP 200 OK and set it to the desired option, i.e. allow or disallow 
reporting the selected channel 

5.3. 1 . 1 A SCF-initiated session initiation 

The SCF shall support the procedures specified in ES 283 003 [20] applicable to an AS acting as an originating UA. 

Upon a cause for a BC session initiation, the SCF shall generate an initial INVITE request as specified in 
ES 283 003 [20] for an AS acting as an originating UA. 

The Request-URI in the INVITE request shall be the public user identity of the UE that is to be invited. The TO header 
shall have the same URI as the Request-URI. 

The SCF shall add a P-Asserted-Identity header containing the PSI (Public Service Identifier) of the BC Service. The 
FROM header shall have the same URI as the P-Asserted-Identity header. 

If the SCF supports the SIP INFO framework, then the SCF shall include the Recv-Info header in the INVITE and set it 
to the desired option, i.e allow or disallow reporting the selected channel 

An SDP offer shall be included in the request. The SDP offer shall be done in accordance with the allowed parameters 
and with media capabilities and required bandwidth for the BC session. 

The SDP offer at media level shall include the following elements: 

• The m-line(s) shall be set according to the mapping defined in clause L.2 for the BC service the SCF wants the 
UE to join. 

• The c-line(s) shall be set according to the mapping defined in clause L.2 for the BC service the SCF wants the 
UE to join. 

• An a=bc_service:BCServiceId line to indicate the BCServiceld (channel) that the SCF wants the UE to join. 

• Optionally one or more a=bc_service_package attributes as defined in annex N. The SCF determines the 
allowed service packages based on the user profile. 

• If the SCF has knowledge of the largest bandwidth of all the BC services included in the session, the b-line 
shall be included and set to this value. 

• An a=recvonly line. 

If the SCF receives a 488 error code with warning 370 Insufficient Bandwidth the SCF may perform a new SIP INVITE 
with a lower maximum bandwidth for BC service the SCF wants the UE to join. This procedure may be repeated. If no 
agreement can be reached the SCF may act accordingly. 

5.3.1.2 Session modification 

Upon receipt of a re-INVITE request or an UPDATE request, the SCF shall follow the procedures defined in 
ES 283 003 [20] concerning the AS acting as a terminating UA or a B2BUA. 

When receiving an SDP offer, the SCF may modify the SDP answer in accordance to the user subscription. If the SCF 
finds a media line not compatible with the user's subscription, it shall set the port of this media line to 0. If none of the 
media lines are acceptable, it shall reply with a 403 error response. 

Upon request of a BC session modification, the SCF shall send a re-INVITE or an UPDATE request, depending on the 
dialogue state, and follow the procedures defined in ES 283 003 [20] concerning the AS acting as an originating UA. 

5.3.1 .3 BC service with trick-play mode 

When supporting BC service with trick play, the BC session can observe two special cases: 

• The Broadcast session is modified to change from Multicast to unicast flow. This is the case in which the UE 
activates the trick play mode. 
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• The Broadcast session with trick play mode is modified to return to normal Broadcast TV. This is the case in 
which the UE deactivates the trick play mode by, e.g. switching channels from a paused channel to another 
live Broadcast TV channels. 

5.3.1 .3.1 Trick-play mode activation 

Within the existing Broadcast TV session, if the session modification request contains Service Action Data with 
IPTVActionDataCommand set to "SwitchToTM", the SCF shall determine the modify request is for transition from 
Broadcast TV to Broadcast TV with trick mode and shall act as a B2BUA, terminating the re -INVITE request and 
sending a INVITE request to initiate a session setup to the MCF in charge of recording the BC service that the user has 
selected. When sending the initial INVITE message to MCF, SCF shall follow the procedures defined in 
ES 283 003 [20] concerning the AS acting as originating UA or B2BUA. 

Prior to that procedure, the SCF shall check that the SDP in the re-INVITE contains the unicast streams description for 
content control and content delivery channels to be sent to the MCF to have the necessary parameter to initiate a session 
towards the MCF. If not, the SCF shall answer to the UE with a 403 error code. 

The value of Request-URI contained in the new session initiation request shall be set to the routable identifier of the 
MCF, i.e. the SIP URI of the MCF. 

The TO header shall contain the identifier of the channel to be trick-played i.e. the BC Serviceld included in the Service 
Action Data XML document or retrieved during session information procedure as defined in clause 5.1.3.5. 

If the content or channel that the user has selected is not enabled for trick play, a SIP error code 403 Forbidden, shall be 
generated as a response. 

The SDP offer sent with the INVITE to the MCF will follow the same pattern as in the CoD session initiation. 

The SDP answer shall contain the same number of media descriptors as in the offer, following the SDP offer/answer 
model as indicated in the CoD session initiation clause. The only difference with that is the inclusion of: 

• h-offset attribute different than 0, as calculated by the MCF indicating the offset in a given program. 

The SIP 200 OK message will be progressed from the SCF to the UE as the response to the session modification. The 
SDP answer in the SIP 200 OK shall contain the same number of media descriptors as the SDP offer in the re-INVITE. 

5.3.1 .3.2 Trick-play mode deactivation 

Within the existing Broadcast TV session, if the session modification request Service Action Data with 
IPTVActionDataCommand set to "SwitchToBC", the SCF shall determine the modify request is for transition from 
Broadcast TV with trick mode to Broadcast TV and shall act as a B2BUA, terminating the re-INVITE request and 
sending a BYE to terminate the session to the MCF. 

When the trick play mode is deactivated by the UE, the SCF will need to unlink the MF from the session in order to 
return to the normal broadcast session. 

Before answering to the UE, the SCF shall check that the m-lines containing the multicast streams have been added by 
the UE and those one containing the unicast media streams have been removed. If not, the SCF shall answer to the UE 
with a 403 error code. 

NOTE: How to add or remove a media stream in SDP conforms to ES 283 003 [20]. 

The SCF will then answer back to the re-INVITE request with a SIP 200 OK for the session to be returned to broadcast 
TV as defined in clause 5.3.1.2. 

5.3.1 .4 Session termination 

Upon receipt of a BC session termination request, the SCF shall follow the procedures defined in ES 283 003 [20] 
concerning the AS acting as a terminating UA. 

Upon receipt of an internal indication that a BC session shall be terminated, the SCF shall send a BYE request and 
follow the procedures defined in ES 283 003 [20] concerning the AS acting as a terminating UA. 
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5.3.1 .5 Procedure for PPV service 

5.3.1 .5.1 PPV Session initiation 

The PPV may use session initiation of BC as described in clause 5.3.1.1, with the following differences: 
The SCF shall examine the SDP parameters. In particular: 

1) It shall examine the a=bc_service parameter. This parameter contains the channel the UE intends to join. If the 
bc_service parameter does not point to a channel that the UE is allowed to join, the SCF enforce the step 2). 

2) If present it shall examine the a=bc_program parameter. This parameter contains the BC program ID the UE 
intends to enjoy. If the bc_program parameter does not point to a program that the UE subscribed the SCF shall 
not accept the offer and shall answer with a 403 error code. If the BC program is not ready to start, i.e. the 
current time is greater than/equal to program start time, the SCF shall not accept the offer and shall answer with a 
403 error code. 

If no a=bc_program parameter is carried, the SCF shall not accept the offer and shall answer with a 403 error 
code. 

5.3.1.5.2 PPV Session termination 

Upon receipt of a BC session termination request, the SCF shall foUow the procedures defined in ES 283 003 [20] 
concerning the AS acting as a terminating UA, which is similar with BC session termination as described in clause 
5.3.1.4. 

When the PPV program ends, SCF shall generate a BYE request and follow the procedures defined in ES 283 003 [20] 
for an originating UE, which is similar with BC session termination as described in clause 5.3.1.4. 

5.3.2 Procedure for CoD service 

The SCF shall support the procedures specified in ES 283 003 [20] applicable to an AS acting as a proxy or B2B UA. 

5.3.2.1 Procedure for liandling missing parameters before session initiation 

When receiving the SIP OPTIONS message, the SCF shall select the appropriate media function (see TS 182 027 [2]) 
and forward the SIP request to the appropriate MCF by changing the "Request-URI" accordingly. 

The SCF shall not change the user-part of the TO header in order to keep the content-id in the OPTIONS request. 

In certain cases, the SCF may also forward the SIP OPTIONS over to a default media function. 

When receiving a 301 or 302 response from the MCF, the SCF shall not forward this message to the UE. 

The SCF may check if the MCF indicated in the contact header is allowed destinations. 

If allowed, the SCF shall use one of the MCF URI indicated in the contact header of this response and use it as a 
destination for the redirected OPTIONS. 

5.3.2.2 UE-initiated session initiation 

When receiving any SIP request, the SCF may examine the request to see if it is compatible with the user's subscription 
(e.g. parental control level). 

If the user is not allowed to initiate a session for the requested content, the SCF shall reply with appropriate, SIP error 

code 403 Forbidden, response. 

The SCF shall select the appropriate media function (see TS 182 027 [2]) and forward the SIP request to the appropriate 
MCF by changing the "Request-URI" accordingly. 

The SCF shall not change the user -part of the TO header in order to keep the content-id in the INVITE request. 
In certain cases, the SCF may also forward the SIP INVITE over to a default media function. 
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When receiving a 301 or 302 response from the MCF, the SCF shall not forward this message to the UE. 
The SCF may check if the MCF indicated in the contact header is allowed destinations. 

If allowed, The SCF shall use one of the MCF URI indicated in the contact header of this response and use it as a 
destination for the redirected INVITE. 

5.3.2.2A SCF-initiated session initiation 

Upon a cause for a CoD session initiation, the SCF shall generate an initial INVITE request as specified in 

ES 283 003 [20] for an AS performing 3rd party call control as an initiating B2BUA, involving coordinated signalling 

with the UE and the MCF. An example protocol flow is provided in clause A.3. lA. 

For the INVITE request to the UE the Request-URl is the public user identity of the UE that is to be invited. The TO 
header shall contain the same URI as in the Request-URl parameter. 

The SCF shall add a P-Asserted-Identity header containing the CoD session that is to be activated. The FROM header 
shall have the same URI as the P-Asserted-Identity header. The URI of the CoD session that is to be activated shall be 
composed of a user and domain part as defined as follows: 

• The user part contains the content identifier in a free string format, as defined in TS 182 027 [2]. 

• The domain part is the Service Provider domain name. 

The INVITE request to the UE may contain an empty session description. 

The UE offers an SDP to the SCF. Upon receiving the SDP from the UE the SCF selects the MCF and uses the SDP 
offer in the INVITE to the MCF. 

For the INVITE request to the MCF the SCF shall add a P-Asserted-Identity header containing the pubUc user identity 
of the invited UE. The FROM header shall have the same URI as the P-Asserted-Identity header. 

For the INVITE request to the MCF the Request-URl is set to the MCF address. The TO header shall include the 
content id of the CoD session that is to be activated in the user part of the URI. 

When the SCF receives the SIP 200 OK with the SDP answer from the MCF the SCF forwards it in the SIP ACK to the 
UE. 

5.3.2.3 Session modification 

Void. 

5.3.2.4 Session termination 

5.3.2.4.1 Session termination using RTSP method 1 

For SCF-initiated CoD session termination, the SCF shall send a BYE Request towards the UE and a BYE request 
towards the MF as specified in ES 283 003 [20]. 

5.3.2.4.2 Session termination using RTSP method 2 

The SCF shall support the procedures specified in ES 283 003 [20] applicable to an AS acting as a proxy or B2B UA 
for call release. 

For SCF-initiated CoD session termination, the SCF shall send a BYE Request towards the UE and a BYE request 
towards the MF as specified in ES 283 003 [20]. 

5.3.2.5 Procedures for liandling COD Service action data 

Upon receiving an INFO request with Content-type set to "application/vnd.etsi.iptvsad-cod-nxml", the SCF retrieves the 
service action data from the INFO message body and either creates or updates the matching object instance. 
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A SIP 200 OK message with no body shall be sent to the originator if the INFO request is successfully received for an 
existing call; the service action data objects shall be created (or updated) according to the data retrieved from the INFO 
message body. 

A "405 Method Not Allowed" shall be sent back to the originator if the SCF has no capability to process INFO 
message. 

A "415 Unsupported Media Type" shall be sent back to the originator if the INFO request contains a body that the SCF 
does not understand. 

A "48 1 Call Leg/Transaction Does Not Exist" shall be sent back to the originator if the INFO request does not match 

any existing session. 

NOTE: The XML schema mapping to the MIME type: "appUcation/vnd.etsi.iptvsad-cod+xml" is available in 
annex K of the present document. 

5.3.3 Procedure for Service Configuration 

The UE uses the XCAP to manage the IPTV user profile (see clause 6.1.2). In order to keep the IPTV services data 
synchronized with the network elements and other terminals that the user might be using, the UE should subscribe from 
the SCF to changes in the XCAP IPTV documents. 

NOTE: Changes may result from XCAP manipulation and/or operator's actions. 

When the SCF receives a SUBSCRIBE request having the Event header field value set to "xcap-diff", the SCF shall 
authorize the request based on the contents of the P-Asserted-Id. If the authorization is successful the SCF shall 
generate a SIP 200 OK response to the SUBSCRIBE request and generate notifications in accordance with 
reference [15] and reference [26]. 

5.3.4 Procedure for PVR Service 

5.3.4.1 Procedures for PVR Service Capture Request 

Upon receiving a SIP MESSAGE request, the SCF identifies the Content-type associated with the MESSAGE request 
and takes appropriate actions as specified below. 

The SCF then checks whether the Service Package id is indeed authorized for the user issuing the request. 

The actual BC service to be recorded/bookmarked is extracted from the XML body carried in the SIP MESSAGE. The 
SCF checks the rights granted to the user for this particular BC service. 

A "415 Unsupported Media Type" shall be sent back to the originator if the MESSAGE request contains a body that the 
SCF does not understand. 

5.3.4.1 .1 Procedures for Impulsive Request 

Case 1: content_type set to "application/vnd.etsi.iptvsad-bc+xml". 

Upon receiving a SIP MESSAGE request with Content-type set to "application/vnd.etsi.iptvsad-bc+xml", the SCF 
retrieves the service action data from the SIP MESSAGE message body and either creates or updates the matching 
object instance: 

If the Bookmark attribute is set to "NOW", the SCF should set it to the current timestamp. 

NOTE: The XML schema mapping to the MIME type: "application/vnd.etsi.iptvsad-bc+xml" is available in 
annex K of the present document." 
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Case 2: content_type set to "application/vnd.etsi.iptvsad-npvr+xnil". 

Upon receiving a SIP MESSAGE request with Content-type set to "application/vnd.etsi.iptvsad-npvr+xml", the SCF 
retrieves the service action data from the SIP MESSAGE message body and either creates or updates the matching 
object instance: 

If NPVRContentId is not present, it should be generated by the SCF itself. 

If the request is acknowledged by the proper entities (e.g. N-PVR servers) RecordStatus is set to "Scheduled" 
by the SCF. 

If the RecordStartDate attribute is set to "NOW", the SCF should set it to the current timestamp. 

The SCF may check the tNPVRStorageLimitlnTime and tNPVRStorageLimitIn Volume parameters associated with the 
user profile to decide whether to allow the user to capture the selected live content. 

Case 3: content_type set to "application/vnd.etsi.iptvsad-cpvr+xnil". 

Upon receiving a SIP MESSAGE request with Content-type set to "application/vnd.etsi.iptvsad-cpvr-nxml", the SCF 
retrieves the service action data from the SIP MESSAGE message body and either creates or updates the matching 
object instance: 

If CPVRContentId is not present, it should be generated by the SCF itself. 

If the request is acknowledged by the proper entities (e.g. C-PVR servers) RecordStatus is set to "Scheduled" 
by the SCF. 

If the RecordStartDate attribute is set to "NOW", the SCF should set it to the current timestamp. 

The SCF may extract the target user identity from the TargetUEId attribute, and find out the corresponding target user 
profile by this user identity. The SCF check the tAuthorizedControlUser parameters associated with the target user 
profile to decide whether to allow the user who sent the C-PVR capture request to capture the selected live content on 
behalf of the target user. 

On all the cases above, a SIP 200 OK message with no body shall be sent to the originator if the MESSAGE request is 
successfully received for an existing call and the service action data objects shall be created (or updated) according to 
the data retrieved from the MESSAGE message body. 

For N-PVR,The the SCF follows relevant procedures to initiate the recording of the content by the N-PVR-MF. Details 
of the procedures are outside scope of the present document. 

ForC-PVR, the SCF follows procedures specified in clause 5.3.4.3 to initiate the recording of the content by the Target 
UE. 

5.3.4.1 .2 Procedures for Offline Request 

Upon receiving a SIP MESSAGE request, the SCF checks to see if the Content-type set to 
"apphcation/vnd.etsi.iptvsad-npvr-Hxml". If so, it follows the procedures outlined in corresponding case 2 in 
clause 5.3.4.1.1. 

5.3.4.2 Procedures for N-PVR Session 

The SCF follows procedures outlined in clause 5.3.2 for handling a COD session. 

NOTE: The XML schema mapping to the MIME type: "appUcation/vnd.etsi.iptvsad-npvr-nxml" is available in 
annex K of the present document. 

5.3.4.3 Procedures for C-PVR Service Recording Session 

The SCF shall check the C-PVR service action data of the user to validate whether the record start-time is reached, the 
SCF may also get the C-PVR session related information, e.g. the BC serviceld and the TargetUEId which is populated 
by SIP instance identifier in clause 5.6.3. 
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Then the SCF sends a SIP MESSAGE to the UE that indicated by the TargerUEId in the service action data using the 
notification procedures described in clause 5.3.6, and includes the following sub-elements of "CPVRRecordlnfo" 
element. 

• The "NotificationReason" in the message body shall be set to "CPVRRecord", the " CPVRRecordlnfo " 
element shall include the following sub-elements: 

The "CPVRContentED", if present, shall be set to the same value that stored in the C-PVR service action 
data. 

The "BCServiceld" in the message body shall be set to same value that stored in the C-PVR service 
action data. 

The "RecordEndDate " in the message body shall be set to t same value that stored in the C-PVR service 
action data. 

5.3.5 Procedure for UGC Service 

5.3.5.1 Procedure for handling UGC declaration request 

Upon receiving a SIP MESSAGE request, the SCF identifies the Content-type associated with the MESSAGE request 
and takes appropriate actions as specified below. 

The SCF shall immediately send a SIP 200 OK response without message body to the originator after the MESSAGE 
request is successfully received; 

The SCF then checks whether the user is authorized for declaring UGC. 

When the MESSAGE request contains message body including transaction-id, the SCF shall initiate another 
MESSAGE request to the originating UE, including the following contents: 

• The Request-URI and the To header in the MESSAGE request shall be the pubUc identity of the originator. 

• From header shall be set to the PSI of UGC service. 

• Call-ID shall be generated by SCF. 

• CSeq shall be generated by SCF. 

• The Content-type header shall include the MIME type of XML documents representing IF*TV service action 
data: "apphcation/vnd.etsi.iptvsad-ugcH-xml" . 

• The message body carries a "UGC items" element described in TS 182 027 [2], clause 7.4.1, including a UGC 
contentID generated by the SCF, and the same transaction-id extracted from the received MESSAGE. 

When the MESSAGE request does contain a message body, the SCF shall treat it as a publication request for UGC 
description information and take the actions described in clause 5.3.5.2. 

The SCF does not need to store the transaction ID as part of the SAD since it is used only during the declaration phase. 

5.3.5.2 Procedure for handling publication request of UGC description information 

Upon receiving a SIP MESSAGE request, the SCF sends back an immediate 200 OK to the originator, as the same 
procedure described in 5.3.5.1. 

The SCF then checks whether the user is authorized to publish UGC description information. 

When the MESSAGE request contains no message body, the SCF shall follow the same procedure as described in 
clause 5.3.5.1. 

When the MESSAGE request does contain a message body, the SCF shall retrieve the UGC contentID and UGC 
description information from the message body, then SCF shall establish the relationship between the UGC contentID 
and the UGC description information and publishes to the interested entities, e.g. SSF. 
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NOTE 1 : How the UGC description information is published from SCF to other entities is out scope of the present 

document. 

NOTE 2: It is up to the Service Provider poUcy when the UGC content has been successfully uploaded but the 
UGC description information is not published, which is out scope of the present document. 

5.3.5.3 Procedure for handling UGC creation request 

When receiving a SIP INVITE request from the UE, the SCF may examine the request and exchanged session 
description to see if it is compatible with the user's subscription (e.g. UGC profile). 

If the user is not allowed to initiate a session for the requested content, the SCF shall reply with appropriate response, 
with SIP error code 403 Forbidden. 

The SCF shall select the appropriate media function (see TS 182 027 [2]) and forward the SIP request to the appropriate 
MCF by changing the "Request-URI" accordingly. 

The SCF shall not change the To header of the SIP request. 

In certain cases, the SCF may also send the SIP INVITE to a default media function. 

When receiving a 301 or 302 response from the MCF, the SCF shall not forward this message to the UE. 

The SCF may check if the MCF indicated in the Contact header is valid destination. 

If allowed. The SCF shall use one of the MCF URI indicated in the Contact header of this response and use it as a 

destination for the redirected INVITE. 

NOTE 1: UGC content creation using upload method, as well as the protocol used for upload are out scope of the 
present document. 

NOTE 2: Procedures for publishing UGC description in clause 5.3.5.1 and UGC declaration procedures in 
clause 5.3.5.2 may also be embedded in the above UGC creation procedures. 

If the SCF has a stored pre-selection for the created UGC, it shall initiate a session initiation to the UE that pre-selected 
the UGC, as described in clause 5.3.2.2A for CoD, and includes the contentID of the pre-selected content in the From 
header. 

5.3.5.4 Procedure for liandling UGC watcliing request 
5.3.5.4.1 UGC pre-selection 

Upon receiving a SIP MESSAGE request for pre-selection of UGC the SCF shall extract the contentID from the 

message body. 

If the contentID is invalid or unknown the SCF shall respond with a 406 Not Acceptable. If the UE is not allowed to 
pre-select the UGC the SCF shall respond with a 403 Forbidden. 

If the SCF accepts the request it shall store the pre-selected contentID and the requesting UE, and send a SIP 200 OK 
response. 

5.3.6 Notification service 

SCF decides to inform the user of various events, e.g. based on the user subscription and/or the specific service logic. 
Then SCF generates and sends a message request for the transport of notification.. Signalling path applies if a single 
user is to be notified e.g. CoD content recommendation, SCF sends the Message via IMS core to the user. Multicast 
media path applies if large group of users are to be notified, e.g. upcoming BC program notification to users watching 
the same BC service, SCF sends the message to the MF which delivers the Message to the users via a multicast channel. 
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5.3.6.1 Procedure for Notification service using signalling path 

The SCF on detection of a trigger event to notify the user, e.g. new CoD availability, incoming call, content 
recommendation, etc., and the SCF decides to notify the UE through signalhng path according to local pohcy, the SCF 
shall generate a SIP MESSAGE request in accordance with ES 283 003 [20] and TS 124 229 [24] as used in 
ES 283 003 [20]. 

The contents of the above SIP method request shall be as follows: 

• The Request-URI of the SIP MESSAGE request shall be set to the public user identity of the intended 
recipient. 

• The From header shall be set to the SIP URI of the SCF. 

• The To header shall be set to the public user identity of the intended recipient. 

• Call-ID shall be generated by the SCF. 

• CSeq shall be generated by the SCF. 

• The Content-type header shall include the registered MIME type of XML documents representing IPTV 
Notification service data: "application/vnd.etsi.iptvnotification-nxml". 

• The message body shall carry the notification data and conform to the XML schema described in annex S: 

NotificationReason shall be present and set to the reason caused the notification: 

■ Contentlnsertion, in the case of content insertion service. 
CPVRRecord, in the case of C-PVR service. 

■ InstantMessage, in the case of instant message service. 

■ IncomingCall, in the case of incoming call management. 

■ ContentRecommendation, in the case of content recommendation service (CRS). 
Contentldentifier shall be set to the content identifier related to the notification, if present. 
NotificationSender shall be set to the identifier of the originator who provides the notification, if present. 
NotificationReceiver shall be set to the identifier of target user, if present. 

IncomingCaUInfo shall be set to the information of the caller, in the case of incoming call management. 

Contentlnsertionlnfo shall be set according to the ad insertion information, in the case of content 
insertion. 

CPVRRecordlnfo shall be set to the information for C-PVR recording, in the case of C-PVR. 

ContentRecommendationlnfo shall be set to the information for content recommendation, in the case of 
CRS. 

MediaPathNotificationlnfo shall not be included. 

MulticastAddress shall not be carried in the body. 

The SCF shall send the SIP MESSAGE request towards the Core IMS according to the procedures of the Core IMS in 
accordance with ES 283 003 [20]. 
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5.3.6.2 Procedure for Notification service using multicast media patli 

When triggered by a notification event associated with a BC service, e.g. user commenting to the BC program, 
recommendations for BC watchers, etc., the SCF shall generate a SIP MESSAGE request outside the dialog or SIP 
INFO message inside the dialog, and then send it to appropriate MCF. The contents of the request shall be as follows: 

• The Request-URI in the MESSAGE request shall be MCF URI. 

• The From header shall be set to the SIP URI of the SCF. 

• The TO header shaU contain the same URI as in the "Request-URI" parameter. 

• Call-ID shall be generated by the SCF. 

• CSeq shall be generated by the SCF. 

• The Content-type header shall include the registered MIME type of XML documents representing IPTV 
Notification service data: "application/vnd.etsi.iptvnotification+xml". 

• The message body shall carry the notification data conforming to the XML schema described in annex S: 

NotificationReason shall be present and set to the reason caused the notification; 

Contentldentifier shall be set to the BC service ID with which the notification is associated, if present; 
NotificationSender shall be set to the identifier of originator who provides the notification, if present; 
NotificationReceiver shall be set to the identifier of target user, if present; 

MediaPathNotificatonlnfo shall be set to the information related to the notification using media path, in 
case of multicast messaging or multicast notification: 

a) MulticastAddress shall be set to the multicast address used for notification delivery, if present. 

b) InstantMessagelnfo shall include the notification content text that the NotificationSender wants to 
send out. 

5.3.7 Procedure for restricted trick play 

When receiving SIP INVITE request for BC with trick mode or CoD services specified in clause 5.3.1.3 and 5.3.2.2, 
SCF shall further acquire the restricted trick play policy per the content identity and/or user's subscription information. 
Following the successful establishment of the session, and if the SCF has restricted trick play policy applicable to the 
selected content, the SCF shall immediately send a SIP INFO message, including the Restricted- Trickplay Info 
Package (defined in clause ZA.2) according to the SIP INFO framework, to the MCF selected for the session. The SCF 
should setup a session towards the UE only until after a confirmation on SIP INFO in order to avoid race conditions. 
The SIP INFO message SHALL include a XML body to describing the restricted trick play policy. The parameters shall 
be included as follows: 

• ContentID: the identifier for a content that SHALL be controlled by the restricted trick play policy. 

• StartTime: the start time that the restricted trick play SHALL be enforced. 

• EndTime: the end time that the restricted trick play SHALL be enforced. 

• RTSPOperation: the RTSP operations that are not permitted. 

The Content-Type header shall be set to "apphcation/vnd.etsi.iptvrestrictedtrickplay+xml". 

NOTE: The XML schema mapping to the MIME type: "application/vnd.etsi.iptvrestrictedtrickplay+xml" is 
available in annex T of the present document. 

Note that the MCF must have indicated its willingness to receive the Restricted-Trickplay Info Package. 
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5.3.8 Procedure for Service Initiation for Remote UE 

5.3.8.1 Procedure for handling the request of remote UE initial procedures 

Upon receiving a SIP REFER request, the SCF shall check whether the user is authorized to perform service initiation 

and the authorized information list may be set by the Target UE. 

If the request is authorized, the SCF then forwards the request to the Target UE. 

5.3.9 Procedures for Playlist liandling 

Playlists that are owned and created by the network can be conveyed using SIP re-INVITE, SIP UPDATE or SIP INFO 
based on the SIP INFO framework. These playlists are typically not visible to the user, and the user cannot control them 
for trick mode purposes. 

At session startup, playlists are conveyed within a SIP INVITE. 

Following the session establishment, conveying the play list using a SIP re-INVITE or a SIP UPDATE implies an 
immediate cessation of any content currently being streamed, if appUcable, and a content switch to the content in the 
conveyed playlist. The conveyed playlist replaces any existing list. 

Following the session establishment, conveying the play list using SIP INFO based on the SIP INFO framework results 
in the conveyed list replacing any existing list.If content is being streamed (from an existing list) when the playlist is 
conveyed, streaming continues until its completion before content from the new play Ust starts streaming. 

5.3.9.1 Network-Owned Playlist procedures for during CoD session initiation 

This procedure is similar to the procedure outlined in clause 5.3.2.2 for CoD session initiation, with the following 
difference: the SCF generates playlist information and passes it in the SIP INVITE request to the appropriate MCE. 
Whether the SCF generates the playlist information and sends it to the MCF depends on the content identifier in the 
Request-URI of the SIP INVITE request. 

The playlist information may be generated in two ways: 

• Statically - according to pre-configured playlist information. 

• Dynamically - generated on demand, potentially taking user profile information into account. 
In the latter case, the SCF may use external components (e.g. an advertising system). 

Before the SCF forwards the SIP INVITE request to the MCF, it adds the playlist information as MIME multi-part to 
the SIP INVITE request. The SCF shall set "Content-Type: multipart/mixed; boundary=unique-boundary" in the SIP 

INVITE request. 

The SCF should ensure that the SDP part of the SIP INVITE request is contained in the first part of MIME multipart 
message and the playlist information is added as a subsequent part of this MIME multipart message. The contents of the 
playUst information shall follow W3C SMIL 2.1 [1]: 

• The playing sequence information of IPTV contents shall be written in element content whose tag name is 
"seq". 

• A "video src=<IPTV content identifier>" shall be present and be set to IPTV Content identifier (e.g. CoDId, 
PVRContentID, etc). The position of this element between "seq" elements indicates the playing sequence. This 
element may include a timing control attribute: "begin", "end" and "dur": 

"begin" attribute is optionally set to the value of the starting point of IPTV Content; 

"end" attribute is optionally set to the starting point of IPTV Content; 
"dur" attribute is optionally set to the duration of IPTV Content; 

"href attribute is optionally set to the multicast content source information (e.g. multicast address) from 
which the content is fetched. 
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Additionally, this element may also include the attribute "skip-content" to identify whether trick play control 
for IPTV content is allowed or not 

"skip-content" is optionally set to the Boolean value. 

There may be one or more playUst entries in a single playlist. 

For each playlist entry with the "skip-content" attribute is present and set to false, the SCF shall generate a trick play 
restriction XML for inclusion in the SDP body as specified in clause 5.3.7 and sends it to the MCF as a part of a MIME 
multipart message. If "skip-content" not present, it shall be interpreted as equivalent to be present and set to true. 

5.3.9.2 Playlist procedures during an existing CoD session 

If the SCF desires to just update the current playUst, the SCF shall send to the MCF a SIP INFO request that includes 
the Playlist Info-Package (defined in clause ZA.5) in this case, and where the body of the SIP INFO request carries the 
playlist information as described in clause 5.3.9. 1 . The content of the playlist information shall follow W3C SMIL 2.1 
[39] as well as in clause 5.3.9.1. Note the Content-Type header in the SIP INFO request shall include the registered 
MIME type of XML documents representing IPTV playlist data: "application/vnd.etsi.playlist+xml". 

The playlist sent by the SCF regarding an ongoing CoD Session overrides any earlier playlist of that session. 

When composing the playlist, the SCF shall populate it in line with the existing CoD session parameters. If the SCF 
desires to stop the streaming the current content immediately and switch to a new content, and a new playlist, it shall 
use a SIP re-INVlTE or SIP UPDATE for that purpose. The body of whichever message used shall include the new 
playlist and populated as described above in clause 5.3.9.1. 

5.3.10 Procedure for Personalised Service Composition 

5.3.10.1 UE-initiated session initiation 

When an SCF receives an initial INVITE request from the UE containing a PSCid, it shall check whether it already has 
a record of the indicated PSCid: 

• If it does, then the SCF shall correlate the session with the PSCid. 

• If it does not, then the SCF shall make a record of the PSCid and correlate the session with the PSCid. 

In both cases, the SCF may perform service logic associated with the PSC, e.g. SCF-initiated session initiation, see 
clause 5.3.10.2. 

5.3.10.2 SCF-initiated session initiation 

When the SCF initiates a session within a PSC, it shall include the PSCid in the SDP offer in the initial INVITE request. 
The PSCid should be globally unique (see clause 5.1.11.2). 

• An a=PSCid: <PSCid> Une indicates the PSCid 
The SCF shall correlate the session with the PSCid. 

5.3.10.3 Session modification 

Sessions within a PSC can be modified using normal session modification procedures, see e.g. clause 5.3.1.2. For SCF- 
initiated modification of a session within a PSC, the SCF shall include the PSCid in the SIP re-INVITE request or 
UPDATE request, depending on the dialogue state. 

• An a=PSCid:<PSCid> hue indicates the PSCid 

The value of the PSCid may be different than in the original INVITE request, which indicates that the session is 
transferred to another PSC. The value of the PSCid may also be empty, which indicates that the session is removed 
from the PSC. 
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For UE-initiated session modification, the SCF shall check the PSCid in the received re-INVITE request or UPDATE 
request. If the PSCid is different from the original PSCid for this session, this indicates that the session is transferred to 
another PSC. If the value of the PSCid is empty, this indicates that the session is removed from the PSC. 

5.3.10.4 Session termination 

Sessions within a PSC are terminated using normal session termination procedures, see e.g. clauses 5.1.3.4 and 5.1.4.4. 
When a session within a PSC is terminated, then the SCF shall remove the correlation between that session and the 
PSCid. When the last session within a PSC is terminated, then the SCF shall delete the record of the PSCid. 

5.3.1 1 Procedure for Personalized Channel (PCh) Service 

5.3.1 1 .1 Procedure for PCh Declaration Request Handling 

Upon receiving a SIP MESSAGE request, the SCF identifies the Request-URI and the Content-type associated with the 
MESSAGE request and takes appropriate actions as specified below. 

The SCF shall immediately send a SIP 200 OK response without message body to the originator after the MESSAGE 
request is successfully received. 

The SCF then checks whether the user is authorized for declaring PCh and initiates another MESSAGE request to the 
UE, including the following contents: 

• The To header in the MESSAGE request shall be the public identity of the originator. 

• If the original SIP MESSAGE included a contact header with a public GRUU or temporary GRUU, then the 
Request-URI shall be set to the recieved GRUU. If the original SIP MESSAGE included a contact header with 
the SIP instance feature tag, and no GRUU. the SCF shall set the Request-URI to the user public identify. 
Furthermore, the SCF shall include the Accept-Contact header and shall set it to the sip instance feature tag. 
Finally if the original MESSAGE did not include the contact header, the SCF shall set the Request-URI to the 
user public identity. 

• From header shall be set to the PSI of PCh service. 

• Call-ID shaU be generated by SCF. 

• CSeq shall be generated by SCF. 

• The Content-type header shall include the MIME type of XML documents representing PCh service action 
data: "appUcation/vnd.etsi.iptvsad-pch-i-xml" . 

• The message body carries a " PCh ItemList " element described in annex K, including a PChld, and optionally 
the initial PCh information generated by the SCF. 

• The message body shall also carry the same "transaction-id" That is extracted from the incoming MESSAGE 
request. 

The SCF does not need to store the transaction ID as part of the SAD since it is used only during the declaration phase. 

5.3. 1 1 .2 Procedure for PCh Operation 
5.3.1 1 .2.1 PCh Session Initiation 

When receiving an INVITE request, the SCF may examine the request to see if it is compatible with the user's 
subscription (e.g. parental control level). 

If the user is not allowed to initiate a session for the indicated PCh, the SCF shall reply with appropriate SIP error code 
403 Forbidden, response. 

After the request is authorized, the SCF retrieves the IPTV service profile to get the PCh information using the PChId 
extracted from the Request-URI, and determines the correct PChltemContentId that is to be played. 
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The SCF selects the appropriate media function (see TS 1 82 027 [2]) and acts as a B2B UA then forwards the ESTVITE 
request to the selected MCF by changing the request accordingly. 

• The Request-URI in the request shall be changed to the SIP URI of the selected MCF. 

• The user-part of the To header shall not be changed in order to keep the PChId in the request. 

• The message body shall include the SDP offer identical with the previous one SCF received. 

• The Content-type header representing the PCh control data include the MIME type of " 
application/vnd.etsi.playlist+xml ", which is defined in procedures for PlayUst handling of clause 5.3.9. 

The message body shall also include the playUst data for PCh, as described in clause 5.3.9.1. 

5.3.1 1 .2.2 PCh Content Item Switch 

After the PCh session has been estabhshed and if there is an overlap between the currently streamed content and a new 
content the SCF determines if it needs to interrupt the ongoing content. 

If the SCF desires to instruct the MCF to stop streaming the current content and switch to a new content, or to simply 
start streaming a new content when nothing is being streamed due to the previous playlist being completed, it shall send 
a SIP UPDATE or SIP re-INVITE to that effect. The body of the SIP request shall include the new playlist as defined in 
Playlist handling of clause 5.3.9, and which shall take precedence over any existing playlist, if applicable. In particular, 
the SIP request shall have the following: 

• The Request-URI, To header and Call-ID shall be identical to those present in the PCh session initiation 
procedure. 

• The CSeq shall be generated by the SCF. 

• The Content-Type header includes the MIME type representing the PCh control data, i.e. 
application/vnd.etsi.playlist+xml", defined in procedures for PlayUst handling in clause 5.3.9: 

The message body shall also include the upcoming content playlist data for PCh, which carries part of or 
the whole list of PCh information:as described in clause 5.3.9. 

5.3.1 1 .2.3 PCh Overlap Handling 

There are several options available for overlap handling. A service provider can support any such options: 
Option 1: Overlap not Allowed at PCh provisioning 

In this option, the overlap will be resolved during the provisioning and configuration phase so that once this phase is 
completed, there will be no overlap to handle. 

NOTE: The ways that option 1 may be implemented are out of scope of the present document. 

Option 2: Overlap Handling in real time through configured policies 

In this option, overlap will be permitted during the configuration and provisioning phase. 

When there is an overlap at the time for playing of upcoming content, the SCF shall take appropriate action according to 
the PChltemServiceType, as below. An example is when a program is extended for linear TV from its original time. 

The SCF shall use the policy configured in the IPTV service profile, or the local policy for overlap handling to 
determine how to handle the conflict, e.g.: 

• Keeps the on-going session alive and the SCF initiates another task for recording the upcoming BC content, by 
using procedure described in clause 5.3.4. 

• Keeps the on-going session alive and the SCF modifies the PCh information to delay the play of upcoming 
CoD content. 

• Modify the session to stop the current content and play the next content item, and stores the offset of the on- 
going CoD content as IPTV service action data at the same time as described in clause 5 .3 . 1 1 .2. 
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• Modify the session to stop the current content to play the next item as described in clause 5.3.11.2, and 
initiates another recording task for the on-going session, as described in clause 5.3.4. 

Option 3: Overlap handling through user interaction 

In this option, interaction with the user is being undertaken so the user can select his preference for dealing with the 
overlap. 

If this case the SCF shall send a SIP INFO request with the PCH-Overlap-Handling Info Package to the UE for choice 
of action, as follows: 

• The Request-URI, To header shall be both set to the user's public user identity. 

• The Call-ID shall be identical to the one estabhshed by the PCh session initiation procedure. 

• The CSeq shall be generated by the SCF. 

• The Content-type shall be set to the MIME type "application/vnd.etsi.iptvsad-pch-overlap-Hxml" which 
representing the PCh conflict option data. 

• The message body shall include the options for action that SCF supports (see annex U). 

NOTE: The above procedures that SCF negotiates with UE for the choice of the overlap handing takes place 

when dynamic overlapping occurred, and not at the PCh schedule configuration stage. For example the 
user is watching an on-going unicast content of the PCh channel and the trick mode operations(pause for 
10 minutes) cause the unicast program overlap with the next upcoming live multicast program( which is 
the next content of the PCh), at this time, SCF uses the above procedures to ask for the choice to handle 
the dynamically occurred overlapping. 

On reception of SIP INFO request, the SCF then examines the Call-ID header. Content-type header to identify the PCh 
conflict choice request from the UE, and then performs relevant actions accordingly. 

Following successful processing of the SIP INFO request, the UE shall send back a SIP 200 OK response to the sender. 
Note that the SCF must have indicated its willingness to receive the Info PCh-Overlap-Handling Package. 

5.3.12 Procedure for Content Insertion 



5.3.1 2.1 Content Insertion at UE Side 

Content insertion at the UE side is a generic capability that allows for inserting content. Content insertion is triggered 
by user input at the UE side or event detection by the UE or SCF. Clause A.6 provides example signalling flows for the 
case where the SCF detects an event and for the case where a user pauses a CoD stream. 

When the SCF detects an event that triggers content insertion at the UE, or is informed of paused content by the UE, the 
SCF shall check the user subscription data to validate whether the UE accepts content insertion service, the SCF may 
also get the session related information, e.g. the SIP dialog info as specificed in RFC 4235 [42]. 

The SCF sends a SIP INFO message to the UE using the notification procedures described in clause 5.3.6. The contents 
of the request message body shall be as follows: 

• The "NotificationReason" shall be set to "Contentlnsertion". 

• The "MessageSender" shall not be included. 

• A "Contentlnsertionlnfo" element shall be included and composed of (see annex S): 

The "Sessionid" shall be set to the Call-ID of the on-going session. 

"ContentlnsertionReason" describes the reason for Contentlnsertion. The currently specified types are 
"Advertising", "PausedContent", and "Generic". 
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The "ContentlnsertionTime" element contains two sub-elements: 

■ The "ContentlnsertionStartTime", if present, shall be set to the exact timestamp from which the 
content is to be inserted to the regular content. The absence of "ContentlnsertionStartTime" means 
it is an immediate content insertion event. 

■ The "ContentlnsertionDuration" in the message body shall be set to the duration of content 
insertion. The SCF can determine the duration of the content insertion depending on e.g. the 
(expected) length of the time interval that is available for content insertion, the user identity, the 
semantic context of the content in the ongoing session, the geographic location of the UE and its 
local time. In the case of content insertion during a pause, the (expected) length of the time interval 
that is available for content insertion is retrieved from the SIP INFO message received from the 
UE. 

If the content is delivered by multicast, the message body shall include a "MulticastContent" element and 
carries the BCServicelD, by which the UE uses to get the indicated content. 

If the content is delivered by unicast, the message body shall include a "UnicastContent" element and 
carries the the CoD content identifier, by which the UE uses to get the indicated content. 

5.3.12.2 Content Insertion at MF Side 

The content insertion is similar with the playhst described in the clause 5.3.9 with the following differences. SCF shall 
check the user subscription data to validate whether the user accept content insertion service, the SCF may also get the 
session related information, e.g. the SIP dialog info as specificed in RFC 4235 [42]. 

When there is content to be inserted to an-going cod session the SCF sends to the MF a SIP INFO request including the 
playhst Info Package in accordance with the SIP INFO framework, and assuming that the MF declared its wilhngness to 
receive the playlist Info Package. The content of the request shall be as follows: 

• The Content-type header shall include the registered MIME type of XML documents representing IPTV 
playlist data: "application/vnd.etsi.playlist+xml". 

• The Recv-Info header is set to the playlist Info Package. 

• The message body shall carry the playlist information for content insertion, as described in clause 5.3.9.1. 

• To indicate the ongoing session, the playlist information in the message body is enriched with the session ID 
of the existing CoD Session, and the offset from which the ad content Ust is to be played. 

• The "a href=<Content Source Link>" element if present shall be set to the multicast address from which the 
inticated content is fetched. 

NOTE 1: How the MF fetches the indicated content by using the content source information is out scope of the 
specification. 

NOTE 2: The "href only used for multicast, and is not applicable to unicat. 

NOTE 3: In order to prevent session modification, the content to be inserted may have the same codec and bit rate 
with the ongoing content. 

NOTE 4: In order to prevent session modification, the content to be inserted may have the same codec and bit rate 
with the ongoing content. 
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5.3.13 Procedures for IPTV Content Marker Service 
5.3.13.1 Procedure for IPTV Content Marker handling 

The IPTV Content Marker handling procedure appUes to storing, updating and removing IPTV Content Markers. 

When receiving a SIP MESSAGE outside an existing SIP dialog request or SIP INFO request with the IPTV-Content- 
Marker Info package (defined in clause ZA.3), based on the INFO Framework, in which the Content-type header is set 
to "appUcation/vnd.etsi.iptvcontentmarker+xml", the SCF shall extract the IPTV Content Marker data defined in 
clause 5.1.14.1 (e.g. StartTimeOflPTVContentMarker, EndTimeOflPTVContentMarker, UserConmient,etc.). 

If the IPTVContentMarkerlD is not set, the SCF shall issue a unique Content Marker ID and store the retrieved Content 
Marker data. 

If the IPTVContentMarkerlD indicated in the received SIP request already exists, the SCF shall update the 
corresponding Content Marker with the received data, if the Expiry Time is not set to -1. If the Expiry Time is not 
present, the SCF shall assign an Expiry Time default value. An Expiry Time Value of shall be interpreted as an 
unlimited Expiry Time. An Expiry Time Value of -1 shall be interpreted as a deletion request and the SCF shall delete 
the indicated IPTV Content Marker data. 

Upon successful completion of above procedure, a SIP 200 OK message response is sent back to the originator. 

The UE can retrieve the content marker ID allocated by the SCF using normal XCAP operations. 

Note that the SCF must have indicated its willingness to receive the IPTV-Content-Marker Info Package. 

5.3.14 Procedure for Targeted Ad Insertion (TAI) 
5.3.14.1 TAI at UE side 

The procedures in this clause apply when SCF has access to the service state of a user. The SCF should subscribe to the 
presence state of a user to detectthe IPTV service state data, as describe in clause 5.1.6. 

NOTE 1: Other types of service state detection are out of scope of the present document. 

If the user's subscription has been configured to accept ad service, the SCF shall extract the "IPTVContentldentifier", 
"ServiceState", "AdInsertionPoint" and other ad specific information from the detected state data as defined in 
clause 8.14.1 of TS 182 027[2J. The SCF may also get the session related information, e.g. the SIP dialog info as 
specificed in RFC 4235 [42]. With the above information, the SCF shall make ad decision for the indicated IPTV 
session. 

NOTE 2: How the SCF selects ads is out scope of this specifiction. When external ad system is involved in ad 
selection, the appropriate specifications may be used for reference. 

After the ad decision has been made, the SCF shall use the content insertion procedures described in clause 5.3.12. 

• The "Sessionid" shall be set to the Call-ID of the on-going session. 

• The "ContentlnsertionStartTime", if present, shall be set to the exact timestamp from which the ad is to be 
inserted to the regular content. The absence of "ContentlnsertionTime" means it is an irmnediate ad insertion 
event. 

NOTE 3: How this information (ContentlnsertionStartTime, EndTime, multicast and unicast) is retrieved is not 
specified in the present release. 

• The "ContentlnsertionEndTime" in the message body shall be set to the ad insertion end time. 

• If the SCF decides to use the content delivered by multicast, the message body shall include a 
"MulticastContent" element and carries the BCServicelD. 

• If the SCF decides to use the content delivered by unicast, the message body shall include a "UnicastContent" 
element and carries the the CoD content identifier for the decided ad content. 
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5.3.14.2 TAIatMFside 

In order to insert the targeted ad, SCF should subscribe to the presence state of a user to detect the IPTV service state 
data, as described in clause 5.1.6. 

NOTE 1: Other types of service state detection are out of scope of the present document. 

After an ad decision has been made, the SCF shall use the content insertion procedures described in clause 5.3.12.2, 
where the encapsulated message body shall carry the IPTV Content Identifier for the indicated ad content. 

NOTE 2: SIP INFO messages are used when the content insertion command is sent within an existing SIP Dialog 
between the SCF and the MCF. 

5.3.1 5 Procedures for Content Switch within a CoD Contentlist 
5.3.15.1 UE-inltlated session Session initiation 

This procedure is similar to the procedure outlined in clause 5.3.9.1 for contentlist handling during CoD session 
initiation with the following difference: the SCF generates the contentlist information and passes it in the SIP INVITE 
request to the appropriate MCF. 

When the SCF forwards the SIP INVITE request to the MCF, the SIP message SHALL carry a XML body lo describe 
the contentUst information.The included parameters shall be as follows: 

• The "content-id" attribute shall be set to the IPTV Content identify, which is associated with a list of 
SwitchedContentltem elements, as follows: 

The "ContentltemID" element shall be set to the Content item identifier to which the current content-id 
may be switched. 

The "ContentltemName" element shall be set to the name of the content item, for UE to present the 
content information to the user. 

Since the SIP message body contains two kinds of data type (SDP and XML), The SCF shall change the Content-Type 
Header to "multipart/mixed", in addition, a boundary parameter value should be included in the Content-Type header. 
Before the start of each content part, a Content-Type header shall be set. For SDP part, the Content-Type header 
SHALL be set to "apphcation/sdp". For XML part, it shall be set to "application/vnd.etsi.iptvcontentswitch+xml". 

5.3.16 Procedures with other IMS Services 
5.3.16.1 Instant Messaging Procedures 

When an Instant Message is required to be sent to UE's that support OMA Instant Messaging according to [50] these 
procedures apply. 

NOTE 1: A UE that follows these procedures is not required to support IPTV related services, for example the UE 
may be a mobile phone with support for IMS Communication Services. Such UEs are out of scope of the 
present document. 

When the SCF requires sending a message to a UE the following procedures shall be followed. 

The SIP MESSAGE request shall include in the Accept-Contact header the Instant Messaging feature tag '+g.oma.sip- 
im' according to [50] and lARI media feature tag 'um:um-xxx:3gpp-application.ims.iari.iptv-application' according 
to [211. 

The body may include information relating to IPTV (for example: TV program reminder/subscription set by the user). 

NOTE 2: If information related to IPTV is included in the message, this mechanism serves as an alternative to the 
procedure in clause 5.3.6; it is intended to be used if different types of IMS devices are targeted, among 
which non-IPTV devices. 

A response of 200 OK from UE indicates successful reception of the SIP MESSAGE. 
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5.3.17 Procedures for Unicast Content Download 
5.3.17.1 UE-initiated Content Download session initiation 

The procedures are similar with the procedures outHned in clause 5.3.2.2 for UE-initiated CoD session initiation, with 
the following differences: the SCF checks the content identifier selects and forwards the SIP request to the MCF which 
is in charge of the download service by changing the "Request-URI" accordingly. 

5.3.18 Procedure for Preview Service 

5.3.1 8.1 Procedures for BC preview session 
5.3.18.1.1 Session initiation 

In the case of either single-screen or multi-screen BC preview, the procedures can refer to BC session initiation as 
described in clause 5.3.1.1. 

NOTE: The SCF may execute the preview policy after accept the session initiation, e.g. only allow 5 minutes 
view time for the user, then send teardown request towards UE. 

5.3. 1 8.2 Procedures for CoD preview session 

The SCF shall support the procedures specified in ES 283 003 [20] applicable to an AS acting as a proxy or B2B UA. 
5.3.18.2.1 Session initiation 

For preview content having its own content identifier, the preview procedures can use the procedures specified in 
clause 5.3.2.2. 

5.3.19 Procedure for Session Transfer 
5.3.19.1 Generic Procedure 

These procedures are generic to all session transfer modes. For all modes, the transferee UE initiates the new session 
that replaces the transferred session. It is assumed that the SCF includes the session transfer functionality based on 
3GPP procedures in that regard. 

5.3.1 9.1 .1 Transferee UE session initiation 

Upon receipt by the SCF for an initial INVITE by a transferee related to session transfer, the SCF shall foUow the 
procedure in clause 5.3.2.2 with the following qualifications: 

• If the request includes the SIP Replace header that refers to a SIP session for which the SCF has no state, the 
SCF shall return an appropriate SIP 403 (Forbidden) response 

• If the request includes the SIP Replace header that refers to a SIP session for which the SCF has a state, then 
the SCF shall first authorize the user for the request. If the user is not authorized then the SCF shall return a 
SIP error. If the user is authorized for the request, then clause 5.3.2.2 is followed with the following 
quahfications: 

If the same MCF of the transferred session can be used, then the SCF shall send a SIP UPDATE (or re- 
INVITE) to update the SIP session leg with the new SDP for the transferee. 

If the same MCF of the transferred session cannot be used, and a new one is required, then the SCF shall 
terminate the SIP leg towards the old MCF, followed by a SIP UPDATE or SIP re-INVITE to the 
transferor to put the media on hold (transferor UE shall not perform any RTSP transactions), and than 
create a new SIP session leg for the requested content using existing procedures as defined in 
clause 5.3.2.2. 
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After the SIP leg for the transferred session is successfully established, the SCF returns a SIP 200 OK to the transferee. 

5.3.1 9.2 Session Transfer - Push Mode 

5.3.1 9.2.1 Transferor UE Locating a Transferee 

To identify a transferee UE for a session, the transferor shall subscribe to the Registration-event package for the public 
user identity of the user as specified in ES 283 003 [20]. The transferor UE shall then locate an appropriate UE from the 
returned information and initiate a session transfer request to it according to clause 5.1.20.2.2. 

5.3.19.2.2 Transferor and Transferee Handling of Session Transfer Request 

Upon receipt by the SCF of a SIP REFER request, the SCF SHALL follow the procedure in TS 124 237 [58], clause 15 
entitled "Roles for inter-UE transfer without establishment of collaborative session". Following that, and if the request 
is successfully authorized, the REFER request is forwarded to the transferee UE. 

The SCF shall receive a SIP 200 OK or a rejection of the transfer request from the transferee, and which it will forward 
to the transferor. 

If the session transfer request is accepted by the transferee, the SCF shall expect a session initiation request to be 
initiated from the transferee. 

Following the successful session initiation by the transferee and the reporting of the successful session initiation to the 
transferor by the transferee through a SIP NOTIFY, the SCF shall terminate the old session by sending a SIP BYE to 
the transferor and shall wait for the arrival of the SIP 200 OK. 

5.4 Media Control Function (IVICF) 
5.4.1 Procedure for CoD service 

The MCF shall support the procedures specified in ES 283 003 [20] applicable to a terminating UA. 

5.4.1 .1 Procedure for providing missing parameters before session initiation 

When receiving SIP OPTIONS request, the MCF shall examine the CoD content identifier present in the user-part of 

the TO header. 

The MCF may decide to redirect the request to another MCF as described in TS 182 027 [2], clause 5.1.3.3. In this case, 
the MCF shall return a 301 response if the content is not managed by this MCF and the MCF indicates one or more 
MCF addresses in the contact header as indicated in ES 283 003 [20]. 

If the MCF responds to the request, the MCF shall answer with the SDP description of the content delivery channel 
conforming to clause 5.4.1.2.1.1, as requested by the request URI. 

5.4.1.2 Session initiation 

When receiving COD session initiation SIP request, the MCF shall examine the CoD content identifier present in the 
user-part of the TO header and the media parameters in the received SDP, if present. 

The MCF may decide to redirect the request to another MCF as described in TS 182 027 [2], clause 5.1.3.3. 

In this case, the MCF shall return a 301 response if the content is not managed by this MCF or 302 response for any 
other reasons (e.g. load-balancing). 

The MCF indicates one or more MCF addresses in the contact header as indicated in ES 283 003 [20]. 
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5.4.1.2.1 



Procedure for establishing tine RTSP content control and content delivery channel 



5.4.1.2.1.1 



MCF as SDP answerer 



In the case when the MCF receives a session initiation request, the MCF shall examine the RTSP SDP parameters and 
shall allocate server ports for the CoD session. If the MCF supports CoD RTSP playback control Method 1 as defined in 
clause 7.2.1, the MCF shall generate an RTSP session ID for the content control channel. The MCF shall also examine 
the media lines of the media channel SDP offer. 

If none of the media lines in the SDP offer are acceptable, it shall reply with a SIP error code 488 Not Acceptable here, 
response. One reason may be that the SDP does not match the indicated content. 

Otherwise, the MCF shall answer with a SIP 200 OK, indicating the SDP answer. If the content that the user has 
selected cannot be found the MCF shall reply with appropriate, SIP error code 404 Not Found, response. 

The SDP parameters for the RTSP channel shall be set as follows: 

• An 'm' Une for an RTSP stream of format: m=<media> <port> <transport> <fmt>: 



The media field shall have a value of "appUcation". 

The port field is setup according to ES 283 003 [20]. The port number is set to the port allocated by the 



• An "a=setup" attribute shall be present and set as "passive" as defined in ES 283 003 [20] indicating that 
connection shall be initiated by the other endpoint (UE) 

(ex:a=setup:passive). 

• An "a= cormection" attribute shall be present and set as "new" as defined in ES 283 003 [20] 
(ex : a=connection : ne w) . 

NOTE: RTSP over UDP is out of scope of the present document. 

• One or more a=fmtp lines representing RTSP specific attributes set as follows: 



An "fmtp:iptv_rtsp h-uri" attribute shall be set to the RTSP URL to be used in the RTSP requests The 
h-uri can be in form of absolute or relative URL If absolute URl is specified then it is used as-is in 
subsequent RTSP requests. If relative URI is specified in form of a media path, then the RTSP absolute 
URL could be constructed by the UE using the IP Address (from c-line) and port (from m-line) as the 
base followed by h-uri value for the media path. 

(a=fmtp:rtsp h-uri=<request-uri>). 

If the MCF supports CoD RTSP playback control Method 1 as defined in clause 7.2.1, the MCF shall 
include a "fmtp:iptv_rtsp h-session" attribute representing the session-id of the RTSP session to be 

created (ex. a=fmtp:iptv_rtsp h-session = <rtsp-session>). 

For content related to BC service with trick-play mode the MCF shall include "fmtp:iptv_rtsp h-offset" 
attribute that indicates where the playback is to start from 

(ex. a=fmtp:iptv_rtsp h-offset = <media-offset>). 



For each media stream controlled by the RTSP content control channel, SDP answer shall include a content delivery 
channel media description set as follows: 

• the "m=" line indicates the type of the media, the transport protocol and the port of the related content delivery 
channel. If an fmt parameter is in the SDP offer it shall be completed with the supported format by the MDF; 

• the "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and 
unicast address of the flow related to the content delivery channel, (ex. c=IN IP4 <IP_ADDRESS>); 



MCF. 



The transport field shall be identical to the one received in the SDP offer. 



The fmt field shall be identical to the one received in the SDP offer, 
(ex. m=application 554 tcp iptv_rtsp). 
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• the "b=" line shall contain the proposed bandwidth. Since the COD media stream is unidirectional the 
bandwidth shall be set to 0, except for the case that the transport is RTP and RTCP is allowed. 

(ex. b=AS : 0) ; 

• an "a=" line with a "sendonly" 
(ex. a=sendonly). 

5.4.1 .2.2 Procedure for establishing the RTSP channel separately 

5.4.1 .2.2.1 MCF as SDR answerer 

When the MCF receives the SDP offer for establishing only the RTSP channel in the session initiation request, the MCF 
shall examine the SDP parameters. 

If the SDP offer is not acceptable, the MCF shall reply with an SIP error response. Else, the MCF shall answer with a 
SIP 200 OK, indicating the SDP answer. 

The SDP parameters for the RTSP channel shall be set as follows: 

• An "m" line for an RTSP stream of format: m=<media> <port> <transport> <fmt>. 

• The media field shall have a value of "application". 

• The port field is setup according to ES 283 003 [20]. Typically, the port number is a port number of 554 (rtsp 
server port) on its "m" line, and the "setup" attribute is set to "passive" indicating that connection shall be 
initiated by the other endpoint (UE). 

• The transport field shall be identical to the one received in the SDP offer. 

• The fmt field shall be identical to the one received in the SDP offer. 

• If "a=setup" attribute is present in the offer, it shall be present and set to "passive" as defined in 
ES 283 003 [20]. 

• If "a= connection" attribute is present in the offer, it shall be present and set to "new" as defined in 

ES 283 003 [201. 

Optionally, an "a=fmtp:iptv_rtsp h-uri" attribute shall be set to the RTSP URL to be used in the RTSP requests The h- 
uri can be in form of absolute or relative URI. If absolute URI is specified then it is used as-is in subsequent RTSP 
requests. If relative URI is specified in form of a media path, then the RTSP absolute URL could be constructed by the 
UE using the IP Address (from c-hne) and port (from m-line) as the base followed by h-uri value for the media path. 
(a=fmtp:rtsp h-uri=<request-uri>). 

5.4.1.3 Session modification 

Upon receipt of a re -INVITE request or an UPDATE request, the MCF shall modify the session as specified in 
ES 283 003 [20] if the request is acceptable to the MCF in accordance with the user subscription. 

In order to modify the session from the MCF side, the MCF shall send a re-INVITE or an UPDATE request. 

The SDP parameters for the RTSP channel shall be set to the same parameters as specified in clause 5.4.1.2.2.1 except 
for the "a=connection" attribute. The attribute shall be set to "existing" as defined in ES 283 003 [20]. 

For each media stream controlled by the RTSP content control channel the SDP offer shall include a content delivery 
channel media description set as follows: 

• The "m=" line indicates the type of the media, the transport protocol the port of the related content delivery 
channel. 

• The "c=" Une shall include the network type with the value set to IN, the address type set to IP4 or IP6, and 
unicast address of the flow of the related content delivery channel. 

• The "b=" line shall contain the proposed bandwidth. 
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• An "a=" line with a "sendonly". 

The MCF shall not modify RTSP channel m-Une description in the SDP if the media delivery streams controlled by 
RTSP are not removed (port not set to zero in m-lines) in the SDP. 

5.4.1 .3.1 Procedure for establishing tine content delivery channel 

5.4.1.3.1.1 MCF as SDP answerer 

When the MCF receives the SDP offer for establishing content delivery channel in the session modification request, the 
MCF shall examine the SDP parameters and answer with a SIP 200 OK, indicating the SDP answer. 

The SDP parameters for the RTSP channel shall be set to the same parameters as specified in clause 5.4.1.2.2.1 except 
for the "a=connection" attribute. The attribute shall be set to "existing" as defined in ES 283 003 [20]. 

The SDP parameters shall include one or more media description sets as follows: 

• The "m=" line indicates the type of the media, the transport protocol and the port. The type of the media, the 
transport protocol shall be identical to the one received in the SDP offer. The port shall be set to the value used 
for the content delivery channel. 

• The "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and 
unicast address of the flow of the related content delivery channel. 

• The "b=" line shall contain the bandwidth. The bandwidth attribute shall be identical to the one received in the 
SDP offer. 

• The "a=" hne with a "sendonly" . 

5.4.1 .4 Session termination 

5.4.1 .4.1 Session termination using RTSP method 1 

Upon receipt of a BYE request, the MCF shall terminate the session as specified in ES 283 003 [20]. 

In order to terminate the session from the MCF side, the MCF shall first close the RTSP session that was established 
during session initiation by closing the underlying TCP connection if existing (e.g. in case of persistent TCP 
connection). The MCF shall then send a BYE request as specified in ES 283 003 [20]. 

5.4.1 .4.2 Session termination using RTSP method 2 

Upon receipt of a BYE request, the MCF shall terminate the session as specified in ES 283 003 [20]. 

In order to terminate the session from the MCF side, the MCF shall first close the RTSP session that was established 
during session initiation by closing the underlying TCP connection if existing (e.g. in case of persistent TCP 
connection). The MCF shall then send a BYE request as specified in ES 283 003 [20]. 

5.4.1 .5 Procedures for liandling COD Service action data 

Upon receiving normal playback RTSP PLAY (scale header set to 1) (see note 1) request from UE, the MCF may send 
a SIP INFO request to the SCF containing the user related IPTV service action data. The content of INFO request shall 

be as follows: 

The value of the Request-URl shall be set to the one used in the related session. 

From and To headers shall be set to the one defined during the session initiation procedure. 

Call-ID shall be set to the same value as that of the CoD session. 

CSeq shall be generated by UE following rules defined in ES 283 003 [20] for request within a dialog. 

The Content-type header shall include the registered MIME type of XML documents representing IPTV 
service action data: "application/vnd.etsi.iptvsad-cod+xml". 
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The message body carries the service action data: the matching "Available CoD" object shall be updated so 
that CoDDeli very Status is set to "Ongoing". 

NOTE 1: This will only be performed when the very first RTSP PLAY (scale header=l) request is received by the 
MCF for a given CoD session (to avoid over flooding the network with unnecessary updates when user 
presses Play subsequently to FFW or FRW). 

In the case of normal end of streaming, MCF may send a SIP INFO request to the SCF containing the related service 
action data. The content of INFO request shall be as follows: 

The value of the Request-URI shall be set to the one used in the related session. 

From and To headers shall be set to the one defined during the session initiation procedure. 

Call-ID shall be set to the same value as that of the CoD session. 

CSeq shall be generated by UE following rules defined in ES 283 003 [20] for request within a dialog. 

The Content-type header shall include the registered MIME type of XML documents representing IPTV 
service action data: "application/vnd.etsi.iptvsad-cod+xml". 

The message body carries the service action data: the matching "Available CoD" object shall be updated so 
that CoDDeUveryStatus is set to "Completed". 

In the case of error occurring in streaming, MCF may send a SIP INFO request to the SCF containing the related service 
action data. The content of INFO request shall be as follows: 

The value of the Request-URI shall be set to the one used in the related session. 

From and To headers shall be set to the one defined during the session initiation procedureFrom and To 
headers shall be set to the public identity of the user issuing the INFO message. 

Call-ID shall be set to the same value as that of the CoD session. 

CSeq shall be generated by MCF. 

The Content-type header shall include the registered MIME type of XML documents representing IPTV 
service action data: "application/vnd.etsi.iptvsad-cod-nxml". 

The message body carries the service action data: the matching "Available CoD" object shall be updated so 
that CoDDeUveryStatus is set to "Failed". 

NOTE 2: The XML schema mapping to the MIME type: "application/vnd.etsi.iptvsad-cod-nxml" is available in 
annex K. 

If the INVITE request received in session initiation contains an AUow header that does not describe INFO, the MCF 
shall not send INFO request of CoD service action data. 

NOTE 3: INFO request may arrive at the UE if the SCF acts as a proxy. Handling of that case is not specified in the 
current release. If the SIP INFO request of service action data resulted in 405 or 415 response, the MCF 
does not send again the INFO request of service action data. 

5.4.2 Procedure for support of BC service with trick play 

As a general rule, the MCF is not involved in the BC service. Only in the case of a user initiating trick play mode of a 
Broadcast TV session, the MCF in charge of recording the requested channel will be Unked to the session. 

At receipt of an INVITE message from the SCF, the MCF will derive the content ID in real time and from the channel 
identifier it received in the TO header then carry out the same steps as described for the CoD session (see 
clause 5.4.1.2) before replying back, in a positive case, with the SIP 200 OK message. 

In the SDP answer, the only difference with regards to the media descriptors compared to a normal CoD session is the 
inclusion of an h-offset attribute different than 0. 

At receipt of the ACK message acknowledging the SIP 200 OK, trick mode can be initiated. 
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When the trick mode is deactivated by the UE, the MF will receive a BYE message as in the CoD session termination. 
The successful release of resources will imply responding with a SIP 200 OK to the SCF. 

NOTE: The MF represents a combination of the MCF & MDF. In this context the MCF functionality is expected 
to be used. 

5.4.3 Procedure for N-PVR Session 

The MF follows procedures outlined in clause 5.4.1 for CoD session initiation, modification and termination 
procedures. 

NOTE: The MF represents a combination of the MCF & MDF. In this context the MCF functionality is expected 
to be used. 

5.4.4 Procedure for UGC Service 

The MCF shall support the procedures specified in ES 283 003 [20J applicable to a terminating UA. 

5.4.4.1 Procedure for handling UGC creating Session 

When receiving UGC creating session initiation SIP request, the MCF shall retrieve the UGC content ID present in the 
To header and the media parameters in the received SDP. 

After that the selected MCF should estabUsh the relationship between UGC contentID and server ports. 

5.4.4.1 .1 MCF as SDP answerer 

In the case when the MCF receives a session initiation request, the MCF shall examine the SDP parameters and shall 
allocate server ports for the UGC session. The MCF shall also examine the media lines of the media channel SDP offer. 

If none of the media lines in the SDP offer are acceptable, it shall reply with a SIP error code 488 Not Acceptable here. 
One reason may be that the SDP does not match the indicated content. 

Else, the MCF shall examine the SDP media description in the SDP offer, when there is an "a=" line with a "sendonly" 
and there is a UGC contentID in the To header, the MCF shall answer with a SIP 200 OK, indicating the SDP answer. 

SDP answer shall include a content deUvery channel media description set as follows: 

• The "m=" line indicates the type of the media, the transport protocol and the port of the related content 
delivery channel. If an fmt parameter is in the SDP offer it shall be completed with the supported format by the 
MDF. 

• The "c=" hne shall include the network type with the value set to IN, the address type set to IP4 or IP6 and 
unicast address of the flow related to the content deUvery channel, (ex. c=IN IP4 <IP_ADDRESS>). 

• The "b=" line shall contain the proposed bandwidth. 

• If the transfer type is included in the SDP offer it shall be copied into the SDP answer. The MCF may use the 
bandwidth and if present the transfer-type attributes in the SDP to police the rate the content is being uploaded. 

The bandwidth attribute indicates the bandwidth that the MF wants the UE to use for sending media. The MCF uses a 
pre-configured value to indicate the desired bandwidth. 

an "a=" line with a "recvonly" 
(ex. a=recvonly). 

NOTE: UGC content creation using upload method, as well as the protocol used for upload are out scope of the 
present document. 
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5.4.4.2 Procedure for handling UGC watching Session 

Upon receiving a SIP INVITE the MCF shall retrieve the contentID from the To header and shall check if it has an 
MDF with the stored content or incoming UGC multimedia stream with that contentID: 

• If the MCF has an MDF with the stored content, it creates a CoD session as described in clause 5.4.1.2. 

• If the MCF has an MDF with the incoming multimedia stream, it creates a mapping between the MDF server 
ports of the incoming UGC multimedia stream and the RTSP server settings for sending the associated UGC 
multimedia stream. The MCF acts as CoD-MCF, see clause 5.4.1.2. 

If the MCF does not have an MDF with the stored content or incoming UGC multimedia stream with the UGC 
contentID it shall respond with a 488 Not Acceptable Here. 

5.4.5 Notification service 

5.4.5.1 Procedure for Notification service using multicast media patli 

Upon receiving a SIP MESSAGE request outside the dialog or SIP INFO request inside the dialog with Content-type 
set to "appUcation/vnd.etsi.iptvnotification+xml", the MCF shall extract MulticastAddress, if present, from the message 
body, otherwise the MCF shall use the Contentldentifier in the message body to obtain relevant multicast address for 
notification delivery. 

NOTE: The multicast address for notification dehvery may be pre-configured on MCF or from management 
entities, which is out scope of this specification. 

A "415 Unsupported Media Type" shall be sent back to the originator if the request contains a body that the MCF does 
not understand. 

A SIP 200 OK message with no body shall be sent to the SCF if the request is successfully received and the notification 
data is disposed successfully. 

5.4.6 Procedure for restricted trick play 

When receiving a SIP INFO message, including the Restricted-Trickplay Info, withinPackage, within a CoD or BC with 
trick modes session, the MCF shall extract the restricted trick play poUcy from the SIP message body and store it for 
enforcement against the content in the concerned session. 

The procedures for establishing the RTSP content control and content delivery channel should follow the description in 
clause 5.4.1.2.1. The procedure for establishing the RTSP channel separately should follow the description in 
clause 5.4.1.2.2. 

Note that the MCF must have indicated its willingness to receive the Restricted-Trickplay Info Package. 

5.4.7 Procedures for Playlist handling 
5.4.7.1 Procedures for updating playlist information 

Upon receipt by the MCF of a SIP INFO request from the SCF that includes the Playlist INFO package, the MCF shall 
discard any other playlist it may have acquired prior to that. Subsequently, the MCF checks the availablity of each 
content Usted in the new playlist. The MCF shall return a SIP 301 response if some of the content indicated in the 
playlist is not controlled by this MCF or a SIP 302 response for any other reason (e.g. load-balancing). There is no 
difference between this procedures and regular CoD procedures in clause 5.4.1 from a viewpoint of the UE. When 
deUvering content to the UE, the MCF shall switch IPTV Content according to the received playlist information. 

If the updated play Ust information is received through SIP INFO, the MF cotinues to stream the current content, if any, 
until its completion. Following that, the MF starts playing the content from the new playlist. 

If the updated play list is received through a SIP re-INVITE or a SIP UPDATE (which implictly stops the streaming of 
any content from the old playlist) the MF stops the streaming of the current content and starts playing content from the 
new playlist (see clause 5.4.7.2). 
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5.4.7.2 Procedures for Content Switching according to playlist information 

When the MCF is instructed switch content, through a SIP re-INVITE or SIP UPDATE, the MCF stops the content that 
is currently being streamed and start streaming the next content based on the playUst. 

5.4.8 Procedure for Personalized Channel (PCh) Service 
5.4.8.1 Procedure for PCh Operation 

5.4.8.1 .1 PCh Session Initiation 

When receiving the INVITE request, the MCF shall examine the PChld included in the user-part of To header, the 
media parameters in the SDP, and the PCh control data received, if present. 

The MCF may store the PCh control data after receiving the request. 

NOTE: The MCF may validate the content item(s) carried in the PCh control data before it sends back the 

response, e.g. verify the source address of the on-demand content, join the multicast group of the live 
content. How the MCF validates the content item is out scope of the the present document. 

Then the MCF shall follow the procedure in clause 5.4.1.2 to handle the request, acting as an SDP answerer for the 
unicast PCh session. 



5.4.8.1 .2 PCh Content Item Switch 

Upon receiving the SIP UPDATE or SIP re-INVITE for a content switch, the MCF shall follow clause 5.4.7 Procedures 
for Playlist handling. The MF shall extract the content source address and the switch start/end time from the playlist, 
and prepare the delivery of upcoming PCh content item by acquiring content from the content source address before the 
switch start time. 

NOTE 1 : The MF represents a combination of the MCF & MDF. In this context the MCF functionality is expected 
to be used. 

NOTE 2: How the MCF acquires content from the content source is out scope of the present document. 

5.4.9 Procedure for Targeted Ad Insertion (TAI) 
5.4.9.1 Procedure for Internal TAI option 

5.4.9.1.1 TAI at UE side 

NOTE: There are no additional procedures needed for the TAI at UE side. 

5.4.9.1.2 TAI at MF side 

If within a SIP dialog and upon receipt of a SIP INFO message from the SCF that includes the Play-List Info Package, 
in accordance with the SIP INFO framework and Content-Type of "application/vnd.etsi.playhst+xml", the MF shall 
follow the content insertion procedure as described in clause 5.4.12 for ad insertion, i.e. extract the ad Content Identifier 
from the encapsulated message body, and perform ad insertion. 

The MF shall repeat the same procedure as above if it receives outside a SIP dialog a SIP MESSAGE with a Content- 
Type of "application/vnd.etsi.playlist+xml". 

Note that the MCF must have indicated its willingness to receive the Play-List Info Package. 
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5.4.10 Procedures for inter-destination media synchronization 

5.4.10.1 Synchronization session initiation 

If a received ESTVITE contains a SyncGroupId, the MCF shall store the value of the rtcp-attribute included in the SDP. 

The MCF shall assign an SSRC value before responding to the INVITE. A SIP 200 OK response to the INVITE shall 
include this SSRC value as part of the SDP, using the attribute from RFC 5576 [46], and include both SyncGroupId and 
rtcp-attribute. The MCF shall also include its CNAME value as part of the attribute: 

• a=ssrc:<ssrc-id> <attribute>:<value> as specified in [46 1. 

• a=rtcp-xr: grp-sync,sync-group=<SyncGroupId>, see clause W.2. 

• a=rtcp:port [nettype space addrtype space connection-address] as specified in [47]. 

SyncGroupId is a 32-bit unsigned integer in network byte order and represented in decimal. The value SyncGroupId=0 
represents an empty SyncGroupId. The value 4294967295 (2^^32-1) is reserved for future use. ssrc-id is a 32-bit 
unsigned integer in network byte order and represented in decimal. 

If the MCF conveys the SDP using RTSP DESCRIBE (i.e. using RTSP method 2), the SDP parameters can be 
equivalent. Alternatively, if the MCF has not assigned an SSRC value during SIP session setup, it assigns one before 
responding to an RTSP DESCRIBE. 

5.4.10.2 Synclironization session modification 

When an SSRC conflict occurs at the transport level, the MF may have to assign a new SSRC value to a media stream. 
If this concerns a media stream that is part of a synchronization group, the MCF shall use the session modification 
procedures to communicate this new SSRC to the SC. 

5.4.10.3 Synclironization session termination 

If the MCF receives session modification request for a media session that is part of a synchronization session, it shall 
check the request for presence of the SyncGroupId. If the SyncGroupId is not present, the MCF shall end the 
synchronization session for that SC. 

5.4.1 1 Procedures for Content Switcli witiiin a CoD Contentlist 
5.4.1 1 .1 UE-initiated Session Initiation 

The handling of session initiation is similar with the CoD session initiation as described in clause 5.4.1.2, with the 
following differences: 

Upon receipt of the SIP INVITE request, the MCF checks that an "a=fmtp:3gpp_rtsp h-Supported" attribute is present 
and set as "3gpp-s witch" under the "m" line for RTSP stream. 

The MCF then extracts the XML body from the SIP INVITE request, and replaces the content ID with the RTSP URL. 

The MCF then returns the SIP 200 OK response with the Content-Type header set to "Content-Type: multipart/mixed; 
boundary=unique-boundary", adds the XML body representing the updated contentlist information as MIME multi-part. 
The MCF also adds an "a= fmtp:3gpp_rtsp h-Supported" attribute and set as "3gpp-switch" imder the "m" line for RTSP 
stream. 



5.4.12 Procedure for Content Insertion at iVIF Side 

When receiving the SIP MESSAGE request with Content-type set to "application/vnd.etsi.playhst-nxml", in case there 
in no ongoing SIP dialog between the SCF and MCF, the MF shall immediately send back a SIP 200 OK response 
without any message body. 



ETSI 



95 



ETSI TS 183 063 V3.5.1 (2011-02) 



When the MCF receives the SIP MESSAGE request carrying the selected content list from the SCF, the MCE checks 
the availablity of each content in the playlist. If "a href=<Content Source Link>" element is present the MCF shall 
contact the source link and fetch the content in case the required content is not on this MF. 

The MCF may also pre-fetch the content prior to the actual time for the content insertion, to achieve the seamless 
delivery of the streams. 

NOTE 1: How the MF fetches the content is not specified in the present document. 

After all information is extracted correctly, the content insertion shall be enforced on the MF, i.e. insert or replace the 
regular content in the on-going session with the content fetched from the content source. The MF may perform 
transcoding or session modification prior to the content insertion start time. 

The MF shall repeat the same procedure as above if it receives within a SIP dialog a SIP INFO message including the 
Play-List Info Package in accordance with the SIP INFO framework and Content-Type of 
"application/vnd.etsi.playlist-Hxml". 

NOTE 2: The MF represents a combination of the MCF & MDF. In this context the MCF functionality is expected 
to be used. 

NOTE 3: The MCF do have indicated its willingness to receive the Play-List Info Package. 

5.4.13 Procedure for Unicast Content Download 

The MCF shall support the procedures specified in ES 283 003 [20] applicable to a terminating UA. 

5.4.13.1 Procedure for handling UE-initiated Content Download session 

When receiving content download session initiation SIP request, the MCF shall examine the content identifier present in 
the user-part of the TO header and the media parameters in the received SDP, if present. 

The MCF may decide to redirect the request to another MCF as described in TS 182 027 [2], clause 5.1.3.3. 

In this case, the MCF shall return a 301 response if the content is not managed by this MCF or 302 response for any 
other reasons (e.g. load-balancing). 

The MCF indicates one or more MCF addresses in the contact header as indicated in ES 283 003 [20]. 

5.4.13.1.1 MCF as SDP answerer 

In the case when the MCF receives a session initiation request, the MCF shall examine the SDP parameters and shall 
allocate server ports for the content download session. The MCF shall also examine the media lines of the SDP offer. If 
none of the media lines in the SDP offer are acceptable, it shall reply with a SIP error code 488 Not Acceptable here, 
response. One reason may be that the SDP does not match the indicated content. 

The MCF may also read the bandwidth and if present the transfer-type attributes in the SDP and shape the rate of the 
content download. 

Else, the MCF shall answer with a SIP 200 OK, indicating the SDP answer. The MCF also add the XML body in the 
SIP 200 OK for the download session description which referenced by the session description URI indicated in 
Request-URI header in the SIP INVITE request. 

If the content that the user has selected cannot be found the MCF shall reply with appropriate, SIP error code 404 Not 
Found, response. 

Since the SIP message body contains two kinds of data type (SDP and XML), The MCF shall set the Content-Type 
Header to "multipart/mixed", in addition, a boundary parameter value should be included in the Content-Type header. 
Before the start of each content part, a Content-Type header shall be set. For SDP part, the Content-Type header 
SHALL be set to "application/sdp". For XML part, it shall be set to "application/vnd.etsi.iptvcontentdownload-i-xml". 
The XML schema can be refer to the TS 102 034 [3], clause C.2.3. 
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The SDP parameters for the HTTP channel shall be set as follows: 

• an 'm' Une for an HTTP connection of format: m=<media> <port> <transport> <fmt>: 

The media field shall have a value of "apphcation" . 

The port field is setup according to ES 283 003 [20]. The port number is set to the port allocated by the 
MCF. Typically, the port number is a port number of 80 (http server port) on its "m" hne. 

The transport field shall be identical to the one received in the SDP offer. 

The fmt field shall be identical to the one received in the SDP offer, 
(ex. m=application 80 tcp iptv_http). 

• an "a=setup" attribute shall be present and set as "passive" as defined in ES 283 003 [20] indicating that 
connection shall be initiated by the other endpoint (UE) 

(ex : a=setup : passive). 

• a "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP 
address of the flow of the related HTTP channel 

(ex. c = IN IP4 <IP_ADDRESS>). 

An "a= connection" attribute shall be present and set as "new" as defined in ES 283 003 [20] 
(ex. a=connection : new). 

Optionally the "b=" line may contain the proposed bandwidth. Since the content download is 
unidirectional the bandwidth shall be set to 0. 
{ex. b=AS:0). 

5.4.14 Procedure for Preview Service 

5.4.1 4.1 Procedures for CoD preview session 

The MCF shall support the procedures specified in ES 283 003 [20] applicable to a terminating UA. 

5.5 Core IMS 

In general, the behaviour of Core IMS entities shall conform to the procedures specified in ES 283 003 [20]. This clause 
provides some further details for specific procedures and services. 

5.5.1 Procedure for Registration 

The behaviour of Core IMS entities when supporting IMS registration shall conform to ES 283 003 [20]. 

5.5.2 Procedure for Service Attacliment 
5.5.2.1 Pusli mode 

The behaviour of Core IMS entities when processing the third-party REGISTER and MESSAGE method shall conform 

to ES 283 003 L20]. 

The S-CSCF sends a third-party REGISTER request to the SDF that matches the Filter Criteria of the service profile 
from the UPSF for the REGISTER event. 

The Initial Filter Criteria shall include the REGISTER method as the prime Service Trigger Point. Examples of service 
trigger points that may be used to build an appropriate IFC are available in annex R. 
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5.5.2.2 Pull mode 

The behaviour of Core IMS entities when processing the SUBSCRIBE and NOTIFY methods shall conform to 
ES 283 003 [20]. 

SUBSCRIBE requests are routed to the SDF using one of the following methods: 

1) The SDF identity received in the Request URI matches a Public Service Identity (PSI) hosted by the SDF. 

2) The SUBSCRIBE request matches an Initial Filter Criteria (IFC) stored against the public user identity of the 
UE. 

The present document does not place any restrictions on the procedures to be used for routing a session to a PSI nor on 
the list of service trigger points to use in building Initial Filter Criteria. 

The Initial Filter Criteria shall include the SUBSCRIBE method as the prime Service Trigger Point. Examples of 
service trigger points that may be used to build an appropriate IFC are available in annex R. 

5.5.3 Procedure for Service Configuration 

Core IMS entities are not involved during service configuration procedures except if the UE subscribes to notifications 
to changes to its user profile, in which case the behaviour of Core IMS entities when processing the SUBSCRIBE and 
NOTIFY methods shall conform to ES 283 003 [20]. 

SUBSCRIBE requests are routed to the SDF using one of the following methods: 

1) The identity received in the Request URI matches a Public Service Identity (PSI) hosted by the SCF acting as 
a front end to manage the user profile. 

2) The SUBSCRIBE request matches an Initial Filter Criteria stored against the public user identity of the UE. 

The present document does not place any restrictions on the procedures to be used for routing a session to a PSI nor on 
the list of service trigger points to use in building Initial Filter Criteria. 

The Initial Filter Criteria shall include the SUBSCRIBE method as the prime Service Trigger Point. Examples of 
service trigger points that may be used to build an appropriate IFC are available in annex R. 

5.5.4 Procedure for Service Selection 

Core IMS entities are not involved during service selection procedures. 

5.5.5 Procedure for CoD service 

The behaviour of Core IMS entities shall conform to the procedure for handling an originating session as described in 
ES 283 003 [20]. 

INVITE requests are routed to the SCF using one of the following methods: 

1) The SCF identity received in the Request URI matches a PubUc Service Identity (PSI) hosted by an SCF 
providing CoD service logic. 

2) The INVITE request matches an Initial Filter Criteria stored against the public user identity of the UE. 

The present document does not place any restrictions on the procedures to be used for routing a session to a PSI nor on 
the list of service trigger points to use in building Initial Filter Criteria. 

The Initial Filter Criteria shall include the INVITE method as the prime Service Trigger Point. Examples of service 
trigger points that may be used to build an appropriate IFC are available in annex R. 
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5.5.6 Procedure for BC service 

The behaviour of Core IMS entities conforms to the procedure for handling an originating session as described in 
ES 283 003 [20], with the additional capability that the P-CSCF transports the service package attributes as defined in 
annex N when present to the RACS as part of BC service resource reservation. It also handles appropriate error 
messages when bandwidth negotiation fails as defined in ES 283 003 [20]. 

INVITE requests are routed to the SCF using one of the following steps: 

1) The well known Public Service Identity (PSI) received in the request URI is mapped to a set of SCFs 
providing BC service logic. 

2) The SCF address is resolved by the INVITE request matching an Initial Filter Criteria stored against the public 
user identity of the UE. 

The present document does not place any restrictions on the procedures to be used for routing a session to a PSI nor on 
the list of service trigger points to use in building Initial Filter Criteria. 

The Initial Filter Criteria shall include the INVITE method as the prime Service Trigger Point. Examples of service 
trigger points that may be used to build an appropriate IFC are available in annex Q. 

5.6 Common Procedures 

NOTE: If the application contains a set of optional features and depending on the type of application (for example 
support of BC or CoD services have different application ids), there might be a need to have multiple IMS 
Application Reference Identifiers for that appUcation that is one IMS Application Reference Identifier per 
sub -feature. 

5.6.1 IMS Communication Service Identifier 

The IMS Communication Service Identifier uniquely identifies the IMS service and associated SIP procedures. The 
IMS Communication Service Identifier defines restrictions to which SIP procedures are possible within a single SIP 
session or standalone transaction and how those SIP procedures are used. The IMS communication service contains an 
aggregation of zero, one, or several media components and the service logic managing the aggregation, represented in 
the protocols used, see ES 283 003 [20]. 

URN used to define the ICSI for the "IMS IPTV Service": urn:urn-7:3gpp-service.ims.icsi.iptv. 

The URN is registered at http://www.3gpp.org/tb/Other/URN/URN.htm . 

Summary of the URN: This URN indicates that the device supports the IMS IPTV Service. 

5.6.2 Session Control Procedures 

The ICSI SHALL be supported by he UE to differentiate the procedures for IPTV service in relation to other IMS 
services. For example, an IPTV unicast media stream may require differentiation from other unicast streams for other 
services like telephony. 

As specified in TS 124 229 [24], core IMS entities will accept a request which does not contain an ICSI. If Release 2 
compliant UE's are supported and the IPTV related ICSI is not supported by the UE the differentiation of services reUes 
on RACS procedures outside the scope of the present specification. 

The "IMS IPTV Service" may support different types of media, including media types listed in the present document. 
The session control procedures for the different media types shall be in accordance with ES 283 003 [20] and the 
present document, with the following additions: 

If the ICSI is used the following applies: 

a) "IPTV" is an IMS communication service and the P-Preferred-Service and P-Asserted-Service headers shall be 
treated as described in ES 283 003 [20]. The coding of the ICSI value in the P-Preferred-Service and 
P-Asserted-Service headers shall be as described in clause 5.6. L 



ETSI 



99 



ETSI TS 183 063 V3.5.1 (2011-02) 



b) The UE shall include the g.3gpp.icsi-ref feature tag equal to the ICSI value defined in clause 5.6.1 in the 
P-Preferred-Service header field in initial requests and responses as described in ES 283 003 [20]. 

c) The UE shall include the g.3gpp. icsi-ref feature tag equal to the ICSI value defined in clause 5.6. 1 in the 
Contact header field in initial requests and responses as described in ES 283 003 [20]. 

d) The UE shall include an Accept-Contact header field containing the g.3gpp. icsi-ref feature tag containing the 
ICSI value as defined in clause 5.6. 1 of ES 283 003 [20] in initial requests. If the user requests capabilities 
other than IPTV, the Accept-Contact header field may contain other feature parameters and feature parameter 
values, and other Accept-Contact header fields may be added to accurately express user preferences as per 
ES 283 003 [20]. 

e) The AS may include the g.3gpp. icsi-ref feature tag equal to the ICSI value defined in clause 5.6.1 in the 
P-Preferred-Service header field in initial requests and responses as described in ES 283 003 [20]. 

f) The AS may include the g.3gpp. icsi-ref feature tag equal to the ICSI value defined in clause 5.6.1 in the 
Contact header field in initial requests and responses as described in ES 283 003 [20]. 

NOTE: How the user indicates other feature parameters and feature parameter values are outside of the scope of 
the present document. 

5.6.3 UE SIP Instance Identifier 

The UE shall support the sip instance feature tag at registration as per clauses 4.1 and 4.2 of RFC 5626 [64]. Its format 
SHALL be identical to the format specified RFC 4122 [65]. The globally unique identifier may be based on the MAC 
address of the equipment which the UE resides on, or any other appropriate scheme as defined in the RFC. If the UE 
only supports release 2 fiinctionaUty the identifier is not required to be supported. 

The Contact header for UE originating SIP requests shall include the sip instance feature tag in all stand-alone (e.g. SIP 
REGISTER) and all initial requests (e.g. SIP INVITE) relating to the IPTV procedures. The initial requests not relating 
to the IPTV procedures (e.g. Instant Messaging) may include the sip instance feature tag. 

If the originating end, either another UE or SCF, is targeting a SIP request to a specific UE the originating end shall 
include the Accept-Contact header with the sip,instance feature tag that corresponds to the target UE. This allows 
targeting a specific user on a specific device. 

For some services such as session transfer it is not appropriate to use this method for targeting a user on a specific 
device. In this case GRUU must be supported by the UE that wishes to use the session transfer service. 

5.6.4 UE Support for GRUU 

A UE that would like to use session transfer services shall support GRUU. To support GRUU, a UE shall conform to 
RFC 5627 [59]. The UE shall include the GRUU in its contact information when it estabUshes an IPTV service that 
requires session transfer. 

The usage of GRUU beyond IPTV is outside the scope of the present document. 

5.7 Synchronization Client (SC) 

5.7.1 Procedures for inter-destination media synclironization 
5.7.1 .1 Synchronization session initiation 

Upon a request for an inter-destination media synchronization session, the SC shall initiate this session using modified 
BC or CoD session initiation or modification procedures, depending on the status of the IPTV service at the moment of 
the request. 

NOTE 1 : There are various ways to convey which services require inter-destination synchronization. This can be 
signalled via SSF information (e.g. the EPG/ESG), through a shared service control session, with 
notifications, recommendations, and others. 
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The SC shall use BC session initiation, described in clause 5.1.3.1, or CoD session initiation, described in 

clause 5.1.4.2, if no current BC or CoD session is active at the moment of the request for a synchronization session. 

If the SC is currently in a BC session at the moment of the request for a synchronization session, it shall use a BC 
session modification, described in clause 5.1.3.2. If the SC is currently in a CoD session at the moment of the request, it 
shall use a CoD session modification, described in clause 5.1.4.3. 

The SC shall include the SyncGroupld as part of the session initiation or modification request. If the SyncGroupld is 
known, it shall be set accordingly. If no SyncGroupld is known, e.g. because the SC is first to setup the inter-destination 
media synchronization, the SC shall include the parameter but leave it empty by selling the value SyncGroupId=0. This 
SyncGroupld shall be set as a media level attribute as rtcp-xr parameter Media Stream Correlation Identifier, see 
annex W. 

• a=rtcp-xr grp-sync,:sync-group=<SyncGroupId>, see clause W.2. 

NOTE 2: The ways that an SC can obtain a SyncGroupld are similar to obtaining a phone conference id. For 

example, one user can request a new SyncGroupld through an off-Une process, and share it with other 
users through an offline process. If the group of users does already have a group identifier, e.g. a phone 
conference id, they may reuse this identifier. Also, the SSC room identifier can be reused for this purpose. 

When the SC receives any SIP requests or responses, the SC shall examine the media parameters in the received SDP. It 
shall be able to deal with the following attributes: 

• a=ssrc:<ssrc-id> <attribute>:<value> as specified in [46]. 

• a=rtcp:port [nettype space addrtype space connection-address] as specified in [47]. 

• a=rtcp-xr: grp-sync,sync-group=<SyncGroupId>, see clause W.2. 

SyncGroupld is a 32-bit unsigned integer in network byte order and represented in decimal. The value SyncGroupId=0 

represents an empty SyncGroupld. The value 4294967295 (2^^32-1) is reserved for future use. ssrc-id is a 32-bit 
unsigned integer in network byte order and represented in decimal. 

The SC shall keep these values for use in synchronization status information and settings instructions procedures, 
described in clause 11. Since the SSRC value may change if a SSRC conflict is discovered at the transport level, the SC 
shall be prepared for this. 

The SC can be involved in multiple synchronized sessions, as long as the sessions and associated services are 
disjunctive. 

5.7.1 .2 Synchronization session termination 

When the SC leaves a synchronization session, e.g. because there are no other SCs involved, it shall generate a 
re -INVITE request or an UPDATE request, depending on the dialogue state, as specified in ES 283 003 [20] for an 
originating UE. 

This re -INVITE shall be an exact duplicate of the current session, but omitting the inter-destination media 
synchronization parameters SyncGroupld, rtcp port and address and SSRC. 

Ending an existing BC or CoD session shall also end any associated synchronization session. 

5.8 Media Synchronization Application Server (IVISAS) 

5.8.1 Procedures for inter-destination media synchronization 
5.8.1 .1 Synclironization session initiation 

Upon a request for session setup or modification, the (session-level) MSAS shall examine the SDP containing the media 
offer for the presence of a SyncGroupld as a media level attribute. If the MSAS can not retrieve a SyncGroupld 
parameter form the SDP, no further procedures apply. 



ETSI 



101 



ETSI TS 183 063 V3.5.1 (2011-02) 



The MSAS shall assign a media-level MSAS using the SyncGroupId. If the SyncGroupId is present and empty, the 
MSAS shall assign a new SyncGroupId to the synchronization session and it shall assign a media-level MSAS address 
and port to be used for this SyncGroupId. If the SyncGroupId is present and is assigned a value, the MSAS shall check 
if this value is known. If this value is known, the media-level MSAS shall lookup the MSAS address and port to be used 
for this synchronization group. If this value is not known, the MSAS shall assign store the SyncGroupId and a media- 
level MSAS address and port to be used for this SyncGroupId. 

NOTE 1: The session-level MSAS can assign address and port values from different media-level MSASes if 
necessary. 

For a BC session setup or modification, the MSAS shall include in its answer to the SC: 

• The SyncGroupId, using the media level attribute a=rtcp-xr: grp-sync,sync-group=<SyncGroupId>, see 
clause W.2. 

• The media-level MSAS address and port to be used, using a=rtcp:port [nettype space addrtype space 
connection-address] as specified in [47]. 

SyncGroupId is a 32-bit unsigned integer in network byte order and represented in decimal. The value SyncGroupId=0 
represents an empty SyncGroupId. The value 4294967295 (2^^32-1) is reserved for future use. 

NOTE 2: In order to distinguish RTCP reports coming from the media-level MSAS from the multicast media 
source, they can have different addresses. 

For CoD session setup or modification, the MSAS shall include these same parameters when forwarding the INVITE or 
UPDATE to the MCF. 

The MSAS shall keep track of the members of a synchronization group and the MSAS address and port used for a 
synchronization group. 

5.8.1 .2 Synchronization session termination 

If the MSAS receives a session modification request of a group member of a synchronization session, it shall check this 
request for the presence of the SyncGroupId. If the SyncGroupId is not present, the MSAS shall remove the SC from 
the synchronization group. 

If the MSAS receives a session termination request from a group member of a synchronization session, it shall remove 

this member from the group. 

The MSAS shall keep track of the members of a synchronization group. If the removal of a member leads to the 
situation that only one member remains in the group, the MSAS should end the synchronization group. The MSAS shall 
do this by sending a re -INVITE or UPDATE to the remaining SC according to existing network-initiated session 
modification procedures. In this modification the synchronization parameters SyncGroupId, rtcp-parameters and SSRC 
are removed. The MSAS will leave all other parameters unchanged. 

If the last member of a synchronization group leaves the synchronization session, the MSAS shall end the 
synchronization group. 



6 Procedures using HTTP for IMS-based IPTV 

6.1 User Equipment (UE) 

6.1 .1 Procedures for service selection 
6.1.1.1 Procedure for service personalization 

For HTTP-based data retrieval, when sending the HTTP request to the SSFs, the UE may indicate personalization 
information to enable personalized answer. This shall be done by adding the following HTTP header to the request: 

• X-3GPP-Intended-Identity to transmit the public identity. 
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• User-agent to transmit UE ID. 

The authentication shall follow TS 187 003 [10], and may be performed either using the mechanisms specified in 
TS 133 222 [14] or HTTP Digest access authentication, as described in ES 283 003 [20]. 

The UE shall implement Transport Layer Security (TLS), as described in RFC 5246 [32]. 

NOTE: Authentication mechanism is specified in the present document. 

6.1.1.2 Request of DVB SD&S 

In the pull model of unicast delivery of a DVB SD&S data, the HTTP protocol shall be used conforming to 
TS 102 034 [3], clause 5.4.2.2. 

The payload id and segments to be retrieved shall be those advertised in the SDF attachment response. 

6.1.1.3 Request of DVB BCG 

6.1.1.3.1 Container-based request 

In the pull model of unicast container-based delivery of DVB BCG, data the HTTP protocol shall be used conforming 
to TS 102 539 [13], clause 4.1.2.2.2. 

6.1.1.3.2 Query mechanism 

In the pull model of unicast query mechanism of DVB BCG data, the HTTP protocol is used to transport SOAP 
messages. This shall be conforming to TS 102 539 [13], clause 4.2. 

6.1.1.4 Request of OM A BCAST ESG 

In the pull model of unicast delivery of an OMA BCAST ESG, the HTTP protocol shall be used conforming to 
OMA-TS-BCAST_Service_Guide, [6], clause 5.4.3. 

6.1.1.5 Request of service action data 

When the UE requests Service Action Data, it shall send HTTP GET request as defined in RFC 2616 [30]. 

The HTTP URL shall be /tispan/serviceactiondata?id=DomainName&Payload=Type where DomainName and Type are 
retrieved from the SSF as defined in clause L.1.3. 

If Payload is set to 0, it means that the UE requests aU available Service Action Data. 

When receiving HTTP 200 OK response, the UE shall evaluate the received XML document as defined in 
clause 6.1.1.6. 

6.1 .1 .5A Request of TV-Anytime Phase 2 XML 

In the pull model of unicast delivery of TV-Anytime Phase 2 XML data, the HTTP and SOAP protocols are used to 
query the SSF. 

When the UE contacts the SSF, it shall send HTTP POST requests as defined in RFC 2616 [30]. The HTTP URL shall 
be /tispan/tva2. The HTTP POST request shall be compliant to [48] and carry a SOAP message body to query the SSF 
as defined in [48]. 

Response code handling of HTTP and SOAP complies to [48]. If the SOAP message contained in the HTTP response 
received from the SSF indicates a successful operation, the UE shall examine the contained TV-Anytime Phase 2 
Metdata. 



ETSI 



103 



ETSI TS 183 063 V3.5.1 (2011-02) 



6.1 .1 .6 Use of service selection information 

The UE shall use parameters received from SSF as defined in clause L.2 for BC session initiation and L3 for CoD 
session initiation. 

NOTE: There is no restriction on the UE to use any parameter received from SSF also for other purposes than 
session initiation, e.g. to present SSF information to the user. 

Concerning broadcast service selection information, BC service package parameters are defined in Package Discovery 
record as described in TS 102 034 [3], clause 5.2.6.5. for DVB SD&S, and in Purchase Item as described in 
OMA-TS-BCAST_ServiceGuide [6], clause 5.1.2.6 for OMA ESG.BC service parameters are defined in 
TS 102 034 [3], clause 5.2.6.2. for DVB SD&S and OMA-TS-BCAST_Service_Guide [6], clause 5.1.2. 

For each BC service package, when parsing the Ust of related parameters the UE shall take the following action: 

information relates to BC Service Package whom the UE has already an entree. The UE shall update 
parameters related to the service package (e.g. the list of related BC services); 

information relates to BC Service Package not known by the UE. The UE shall store parameters related to the 
service package. 

For each BC service, when parsing the list of related parameters the UE shall take the following action: 

information relates to a BC service whom the UE has already an entree. If present, the UE shall update stored 
BC services parameters; 

information relates to a BC service not known by the UE: the UE creates a new entree for this BC service. If 
present, it shall store at least multicast and source address(es), port, transport and codecs information related to 
the BC service. 

The UE may store a part of the EPG information covering certain period of time and refresh this information 
periodically This avoid the UE to contact the SSF every time the user needs to consult the EPG. 

If the UE is unable to contact any discovered SSF, it shall not delete stored information. 
Concerning Service Action Data record, the UE shall use n-PVR, CoD and BC data as follows: 

• if the data type indicates n-PVR service action data, the UE shall use the retrieved data as defined in 
clause 5.1.7; 

• if the data type indicates CoD service action data, the UE may use "CoDoffset" parameter to initiate CoD 
session related to the indicated Content-Id as defined in clause 7.1.1.2; 

• if the data type indicates BC service action data, the UE may use "BCServiceld" parameter to indicate the 
channel the UE intend to join in BC session initiation (see clause 5.1.3.1). 

6.1 .1 .7 Query for IPTV Content Marker 

When the UE requests IPTV Content Marker, it shall send the HTTP POST request defined in RFC 2616 [30]. 

The HTTP URL shall contain the domain name of the SSF and end with /tispan/iptvcontentmarker. 

The HTTP POST request may contain the following parameters to filter the IPTV Content Marker data retrieval on the 
SSF side: 

• IPTVInformationDataCommand shall be set to "Retrieval". 

• IPTVContentMarkerIDs=<lPTVContentMarkerlDs> indicate the hst of specific IPTVContentMakerlD. 
Wildcards ('*','?') may be allowed, depending on the capabilities of the query processor implementation. 
Multiple IPTVContentMarkerlDs shall be separated by space character. 

• IPTVContentIDs=<lPTVContentIDs> indicate the list of specific IPTVContentlD. Wildcards ('*','?') may be 
allowed, depending on the capabilities of the query processor implementation. Multiple IPTVContentlDs shall 
be separated by space character. 
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• owneruserIDs=<owneruserIDs> indicate the list of specific owneraserlD. Multiple owneraserlDs shall be 

separated by space character. 

• maxresults=<MaxResults> indicate the maximum number of the query results. There shall be at most one 
number of maximum results supplied. 

When receiving HTTP 200 OK response, the UE shall evaluate the payload in the HTTP response, which contains the 
IPTV Content Markers as defined in clause 6.3.1.7. 

The XML document of IPTV Content Markers to indicate a Content Marker Retrieval in HTTP Response is defined in 
annex V. 

An SSF technology for IPTV Content Marker handling is described in clauses 5.2.2.3 and L.4. 

6.1 .2 Procedure for service configuration 

6.1.2.1 General 

The UE implements the role of an XCAP client, as described in RFC 4825 [9], in accordance with the IPTV application 
usage specified in annex B. 

The UE shall implement HTTP Digest access authentication, as described in ES 283 003 [20]. 
The UE shall implement Transport Layer Security (TLS), as described in RFC 5246 [32]. 

On sending an HTTP request, the UE may indicate the user's identity intended to be used with the SCF or stand-alone 
XDMS by adding an HTTP X-3GPP-Intended-Identity header (see TS 124 109 [11]) to the outgoing HTTP request. 

6.1 .2.2 Subscription for notification of state clianges in XML document 

In order to keep the IPTV services data synchronized with the network elements and other terminals that the user might 
be using, the UE should subscribe to changes in the XCAP IPTV documents by generating a SUBSCRIBE request in 
accordance with reference [15] and reference [26]. 

6.1 .3 Procedures for Unicast Content Download 

6.1 .3.1 Request of Content Download 

Once the UE has received the SIP 200 OK from the MCF, it extract the XML body of the download session description, 
and sends the HTTP GET request to the URL obtained in download session description, the detail can refer to the single 
server unicast download as defined in TS 102 034 [3] clause 10.6.3.2. The HTTP "Connection" header shall be set to 
"Keep-Ahve" to require persistent TCP connection. 

6.2 Service Control Function (SCF) 
6.2.1 Procedure for service configuration 

6.2.1.1 General 

An Application Server implements the role of an XCAP server as described in RFC 4825 [9]. 

6.2.1.2 Manipulation acceptance 

When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for manipulating or fetching a 
resource list, the XCAP server shall first authenticate the request and then perform authorization. 

The SCF shall implement HTTP Digest access authentication as described in ES 283 003 [20]. 

The SCF shall implement Transport Layer Security (TLS) as described in see RFC 5246 [32]. 
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Clause 6.2.1.3 provides more details on the authentication and authorization of HTTP requests. 

Afterwards the XCAP server shall perform the requested action and generate a response in accordance with 
RFC 4825 [9] and the IPTV application usage specified in annex B. 

6.2.1 .3 Authentication and autliorization 

An Authentication Proxy (AP) may exist between the UE and the SCF, in which case the behaviour of the AP is 
assumed to conform to TS 183 023 [12]. 

If an Authentication Proxy (AP) is provided in the path of the HTTP request, then the SCF receives an HTTP request 
from a trusted source (the AP) and contains an HTTP X-3GPP-Asserted-ldentity header (TS 124 109 [11]) that includes 
an asserted identity of the user. In this case the SCF does not need to authenticate the user, but just provide 
authorization to access the requested resource. 

If an HTTP X-3GPP-Asserted-Identity header (TS 124 109 [1 1]) is not present in the HTTP request or if the request is 
received from a non-trusted source, then the SCF needs to authenticate the user prior to providing authorization to the 
XCAP resource by applying the following procedures. 

On receiving an HTTP request that does not contain an Authorization header the SCF shall: 

a) challenge the user by generating a 401 Unauthorized response that contains the proper Digest authentication 
parameters (e.g. realm), according to ES 283 003 [20]. Provisioning of credentials to authenticate the user is 
outside the scope of the present document; and 

b) forward the 401 Unauthorized response to the sender of the HTTP request. 
On receiving an HTTP request that contains an Authorization header, the SCF shall: 

a) apply the authentication procedures defined in ES 283 003 |20|; and 

b) authorize or deny authorization depending on the authenticated identity. 

6.2.1 .4 Subscription acceptance and notification of state clianges in XML document 

When the SCF receives a SUBSCRIBE request having the Event header field value set to "xcap-diff", the SCF shall 
authorize the request based on the contents of the P-Asserted-Id. If the authorization is successful the SCF shall 
generate a response to the SUBSCRIBE request and generate notifications in accordance with 
references [15] and [26]. 

6.3 Service Selection Function (SSF) 
6.3.1 Procedure for service selection 

6.3.1 .1 Authentication and authorization for personalized service selection 
information 

In case of service selection personalization the SCF shall authenticate the user. 

The authentication shall follow TS 187 003 [10], and may be performed either using the mechanisms specified in 
TS 133 222 [14] or HTTP Digest access authentication as described in ES 283 003 [20]. 

The SSF shall implement Transport Layer Security (TLS) as described in RFC 5246 [32]. 

An Authentication Proxy (AP) may exist between the UE and the SSF in which case the behaviour of the AP is assumed 
to conform to TS 183 023 [12] and TS 187 003 [10]. 
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If an Authentication Proxy (AP) is provided in the path of the HTTP request, then the SSF receives an HTTP request 
from a trusted source (the AP) and the request contains an HTTP X-3GPP-Asserted-Identity header (TS 124 109 [1 1]) 
that includes an asserted identity of the user. In this case the SSF does not need to authenticate the user, but just provide 
authorization to access the requested resource. 

If an HTTP X-3GPP-Asserted-Identity header (TS 124 109 [1 1]) is not present in the HTTP request or if the request is 
received from a non-trusted source, then the SSF needs to authenticate the user prior to providing personalize 
information by applying the following procedures: 

On receiving an HTTP request that does not contain an Authorization header the SSF shall: 

a) challenge the user by generating a 401 Unauthorized response that contains the proper Digest authentication 
parameters (e.g. realm), according to ES 283 003 [20]. Provisioning of credentials to authenticate the user is 
outside the scope of the present document; and 

b) forward the 401 Unauthorized response to the sender of the HTTP request. 
On receiving an HTTP request that contains an Authorization header, the SSF shall: 

a) apply the authentication procedures defined in ES 283 003 [20]; and 

b) authorize or deny authorization depending on the authenticated identity. 

6.3.1.2 Procedure for service personalization 

If personalization headers are present in the query from the UE, the SSF shall extract the UE ID and/or the public user 
identity information that is present in the query to customize/personaUze the service information that is returned in the 
query response. 

The SSF shall use the public user identity that is specified in the X-3GPP-lntended-ldentity header or the 
X-3GPP-Asserted-ldentity header (as defined in clause 6.3.1.1) if an authentication proxy is used to fetch the 
corresponding IPTV user profile associated with the user. For instance, the Parental Control level (if present) should be 
used to remove unsuitable elements from the COD listings that are retumed to the UE. 

The SSF shall use the public user identity that is specified in the X-3GPP-lntended-ldentity header or the 
X-3GPP-Asserted-Identity header (as defined in clause 6.3.1.1) if an authentication proxy is used and the UE-ID that is 
specified in the user-agent header to fetch the corresponding UE profile information from the IPTV user profile 
associated with the specified IPTV user. If present, the SSF should use the UE capabilities to return back service 
information matching the capabilities supported by the specific UE. For example, The UE Capabilities information such 
as supported video frame rates and supported encodings can be used to identify the decoding and display capabilities of 
the UE and can be used to return back only SD content listings to UE that has no HD support. 

The fetching of IPTV user profile shall be done towards a dedicated database or UPSF within a service provider domain 
as specified in TS 182 027 [2], clause 7.2.4. 

NOTE: The support of personalization for multiple service providers from a single UPSF as well as the interface 
between the SSF and the dedicated database is out of scope of the present document. 

6.3.1.3 Delivery of DVB SD&S 

In case an SSF receives an HTTP request for unicast delivery of DVB SD&S data it shall act as a so-called SD&S SSF. 

When the SD&S SSF receives an HTTP GET request, if personaUzation headers are presents it shall use those headers 
in order to build a personalized response. 

The SD&S SSF shall send an HTTP response conforming to TS 102 034 [3], clause 5.4.2. 

The body of the HTTP response shall contain an XML document with the appropriate SD&S offering record, 
conforming to TS 102 034 [3], clause 5.2.6. 

Available Offering records are: 

• The Broadcast Discovery record (clause 5.2.6.2) is a Ust of IPTV services. 
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• The Package Discovery record (clause 5.2.6.5) is a list of packages, a package being a list of pointers to 
services that are advertised in the broadcast discovery record. 

• The BCG Discovery record (clause 5.2.6.6) is a Ust of BCGs, and for each of them the location of the BCG 
SSF(s) to connect to the BCG server(s) (DVB multicast and unicast modes are available, plus a specific Query 
mechanism). 

The type of TV- Anytime content carried in the Payload shiill be advertised by the SSF, conforming to 
TS 102 539 [13], clause 4.1.2.1 table 2. 

When present, the DVBSTP@Source or the HTTP@Location of the TransportMode parameter in BCG 
Discovery Record represent respectively the multicast address (when service selection data are 
multicasted) and the URI (when service selection is done through HTTP) used by the BCG SSF. 

When using the DVB pull mode without SOAP, the SD&S SSF shall include the Segment information. 

6.3.1.4 Delivery of DVB BCG 

In case an SSF receives an HTTP request for unicast container-based deUvery of DVB BCG data it shall act as a 
so-caUed BCG SSF. 

6.3.1.4.1 Container-based delivery 

When the BCG SSF receives an HTTP GET request, if personalization headers are presents it shall use those headers in 
order to build a personalized response. 

The BCG SSF shall send an HTTP response conforming to TS 102 539 [13], clause 4.1.2. 

The body of the HTTP response shall contain an XML document with the appropriate BCG data, conforming to 
TS 102 539 [13]. 

6.3.1.4.2 Query response 

When the BCG SSF receives a BCG Query SOAP message, if personalization headers are present it shall use those 
headers in order to build a personalized response. 

The BCG SSF shall send a SOAP response conforming to TS 102 539 [13], clause 4.2. 

6.3.1.5 Delivery of OM A BCAST ESG 

In case an SSF receives an HTTP request for unicast delivery of an OMA BCAST ESG it shall act as a so-called ESG 
SSF. 

The procedure for retrieving OMA BCAST service selection information is employed to retrieve one or more Service 
Guide Dehvery Descriptors (SGDD) and/or Service Guide Delivery Units (SGDU). The SGDD describes service level 
information as well as access information to the Service Guide fragments. The SGDU is the transport-independent 
network structure for encapsulating Service Guide fragments. 

When the ESG SSF receives a HTTP POST request, if personalization headers are presents (in the form of key-value 
pairs) it shall use those headers in order to build a personalized response. For instance, the ESG SSF may use the 
provided user identity to retrieve the associated Parental Control Level in the IPTV user profile. This Parental Control 
Level would then be used to remove non suitable elements from the ESG data that are sent back. The provided user 
identity may also be used to retrieve a personalized ESG using the method in 

OMA-TS-BCAST_Service_Guide-Vl_0 [6], clause 5.4.3.3.The ESG SSF shall send a HTTP response conforming to 
OMA-TS-BCAST_Service_Guide-Vl_0 [6], clause 5.4.3.1. The body of the HTTP response shall contain an XML 
document with SGResponse data, conforming to OMA-TS-BCAST_Service_Guide-Vl_0, clause 5.4.3.1.1 [6]. 

6.3.1 .6 Delivery of Service Action Data 

When receiving HTTP GET request for service action data, the SSF shall evaluate "Payload" parameter in the HTTP 
query and respond with the appropriate XML document as defined in annex D. 
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If the "Payload" parameter indicates BC service action Data, the message body carries the following parameters: 

• IPTVActionDataCommand shall be set to "Notify" . 

• Notify shall be set to "IPTVBcActionData" . 

• BCServiceld is set to the value of the channel previously reported by the UE in BC session information 
procedure as defined in clause 5.1.3.5. 

• If available, the following parameters shall be present: ProgrammelD, Bookmark, BookmarkExpiryTime. It 
means that a record exists for such a bookmark and that the UE can use it as an N-PVR content. 

If the "Payload" parameter indicates CoD service action Data, the message body carries the following parameters: 

• IPTVActionDataCommand shall be set to "Notify" . 

• Notify shall be set to "IPTVCodActionData" . 

• For each content identified by a CoDId: 

CoDDelivery status shall be present and set to the value stored for that content; 
CoDOffset shall be present and set to the value stored for that content. 
If the "Payload" parameter indicates N-PVR service action Data, the message body carries the following parameters: 

• IPTVActionDataCommand shall be set to "Notify" . 

• Notify shall be set to "IPTVNpvrActionData" . 

• For each N-PVR content identified by a NPVRContentId, the following parameters shall be present if 
available: BCServiceld, RecordStartDate, RecordEnDate, RecordStatus, RecordOffset and RecordExpiryTime 
shall be present if available. 

If the "Payload" parameter is set to "ALL", the SSF shall send all available Service Action Data as defined above. 
If no information is available for the requested type, the SSF shall answer with an HTTP 404 error code. 

6.3.1 .7 Delivery of IPTV Content Marker 

For fine grained access control, The SSF shall check two parameters: 

• IPTVContentMarkerSourceUser is generated by other users' IPTVContentMarkerAuthorizedViewUser 
parameter and indicates that the requesting user can share which users' IPTV Content Marker. 

• ForbiddenViewUser can be set to the particular IPTV Content Marker by the owner when the owner does not 
want to share this IPTV Content Marker with specific users included in 
IPTVContentMarkerAuthorizedView User parameter. 

When receiving HTTP request for IPTV Content Markers with the IPTVInformationDataCommand parameter set to 
"Retrieval", the SSF shall extract the User ID and lookup the IPTV Content Marker data associated to that User ID. It 
shall also examine the IPTV User Profile associated to that User ID in order to look up the 

IPTVContentMarkerSourceUser parameters of the BC, CoD and PVR profiles. The SSF shall attempt to retrieve the 
IPTV Content Marker data associated with these other users' User ID only if the other users' 

IPTVContentMarkerAuthorizedViewUser parameters of the relevant IPTV service profile indicate the requesting User 
ID. Additionally, the SSF shall check for each retrieved IPTV Content Marker if the parameter ForbiddenViewUser is 
present. If this ForbiddenViewUser pzxameXer is present, the SSF shall check whether the requesting User ID is 
included in this parameter. If that User ID exists in ForbiddenViewUser, the SSF shall remove that particular IPTV 
Content Marker data from the response data set. After all ForbiddenViewUser parameters of all IPTV Content Marker 
data have been checked, the SSF shall respond with the IPTV Content Markers remaining in the response data set. 

The XML document of IPTV Content Markers to indicate a Content Marker Retrieval in HTTP Response is defined in 
annex V. 
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Upon receiving an HTTP based IPTVContentMaker retrieval request, the SSF shall send an HTTP response. The body 
of the HTTP response shall contain an XML document defined in clause 6.1.1.7 and contain only data that matches the 
filter parameters passed in the HTTP request. 

6.3.1 .8 Delivery of TV-Anytime Phase 2 XML 

When the TV-Anytime Phase 2 based SSF receives an HTTP POST request, if personalization headers are present it 
shall use those headers in order to build a personalized response. For instance, the provided IPTV user profile may be 
used to retrieve the personalized EPG data. Further, the SSF shall examine the SOAP message carried in the HTTP 
request and process it according to [48]. It shall process the query, and build a SOAP response compUant with [48]. The 
SSF shall send that SOAP response to the UE in a HTTP response compliant with [48]. 

6.4 Stand-Alone XMDS 

6.4.1 Procedure for service configuration 

6.4.1.1 General 

The stand-alone XDMS implements the role of an XCAP server as described in RFC 4825 [9]. 

6.4.1.2 Manipulation acceptance 

The behaviour of a stand-alone XDMS server with regards to XCAP is identical to the behaviour of an SCF as 
described in clause 6.2. 

6.4.1 .3 Authentication and authorization 

The behaviour of a stand-alone XDMS server with regards to XCAP is identical to the behaviour of an SCF as 
described in clause 6.2. 

6.4.1 .4 Subscription acceptance and notification of state changes in XML document 

A stand-alone XDMS does not support subscriptions to profile changes. Subscriptions to profile changes are directed to 
the SCF acting as a front-end to the XDMS. 

6.5 Media Function (IVIF) 

6.5.1 Procedures for Unicast Content Download 
6. 5.1 .1 Response of Content Download 

Once the MF has received the HTTP GET request from the UE, it should return HTTP response with the content file 
corresponding to the URL obtained in the received HTTP GET. Also the HTTP "Connection" header shall be set to 
"Keep-Alive" to indicate it is a persistent TCP connection. The detail can also refer to the single server unicast 
download as defined in TS 102 034[3] clause 10.6.3.2. 

NOTE: The Xd interfaces are used for the UE to download the content. And the MCF and MDF are treated as a 
whole in release 3. 
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7 Procedures using RTSP for IMS-based IPTV 

This clause specifies how the playback control, e.g. in the CoD Service, through RTSP is achieved. Two approaches 
have been identified: 

• "Method 1": clauses 7.1.1 and 7.2.1 describe a protocol which uses a subset of the RTSP methods defined in 
RFC 2326 [8], interpreting SIP INVITE and SIP BYE as triggers for RTSP Session Initiation and termination. 

• "Method 2": clauses 7.1.2 and 7.2.2 describe a protocol which follows RFC 2326 [8J. 

7.1 User Equipment (UE) 

7.1 .1 Procedures for RTSP playback control (Method 1 ) 

7.1.1.1 Introduction 

The UE shall support the following RTSP methods for RTSP playback control: 

• PLAY (UE to MCF). 

• PAUSE (UE to MCF). 

• GET_PARAMETER (UE to MCF). 

• SET_PARAMETER (UE to MCF). 

• ANNOUNCE (MCF to UE). 

• OPTION (UE to MCF). 

NOTE: The UE is not required to use OPTION method since all the specified methods are mandatory. The 
OPTION method is included simply to allow for future compatibility and easier introduction of new 
optional methods. 

The methods shall use the same session id as specified in the SDP h-session attribute. 

7.1.1.2 Media playbacl< initiation procedure 

Upon a request to start playback the UE shall send an RTSP PLAY message to the MCF using the h-uri attribute 
received in the SDP. If a domain address is used in the RTSP URL the UE shall not perform DNS lookup. The IP 
header for the RTSP PLAY message shall be set to the IP address from the connection line ("c=") in the SDP answer 
and the port from the media line ("m="). 

NOTE: The UE does not perform DNS lookup in order to avoid misahgning the information conveyed in the 
SDP. 

The RTSP fields in the RTSP PLAY message shall be filled as follows: 

• The RTSP URL shall be set to the value retrieved from the SDP h-uri attribute in the case of an absolute URI. 

If the value of h-url is a relative URI that is in the form of a media path, then the RTSP absolute URL is 
constructed by the UE using the SDP IPAddress (from c-line) and port (from m-hne) as the base followed by 
h-uri value for the media path. 

(e.g. rtsp://10 .5.1. 72 : 22554/TV3/823527). 

• If the h-offset attribute is present in the SDP, then the Range parameter in the first RTSP PLAY message shall 
be included and set to the value retrieved from this SDP h-offset attribute. Else: 

the Range parameter may be included and set to the value retrieved in the CoD SAD from the SSF in 
case the user wants to resume a pending CoD at the time it was previously stopped. 
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• If Range parameter is not sent by the UE, the stream will play from the beginning, 
(e.g. Range: npt = <OFFSET>-). 

7.1.1.3 Media playback modification procedure 

Upon a request to modify playback the UE shall send an RTSP PLAY message with a request to modify the position, 
speed and/or direction of playback. The UE changes the direction and/or speed of playback by including a Scale 
header or change the position of playback by including a Range header. 

• Scale header is set as follows: 

1 indicates normal play. 

If not 1, the value corresponds to the rate with respect to normal viewing rate. 
A negative value indicates reverse direction. 
If the request is to pause playback, the UE shall send an RTSP PAUSE message. 

7.1 .1 .4 Media playback information retrieval and setting procedure 

Upon a request to retrieve playback information the UE shall send an RTSP GET_PARAMETER message. The UE 
shall create a message with a content type: text/parameters. 

The parameters the UE wants to retrieve shall be set in the body, one parameter per Une.The UE may retrieve the 
following information: 

• position: 

The position in the media in seconds. 

• scales: 

The allowed scales that can be used in the PLAY request. 

• duration: 

The total duration in seconds of the media to be played. 

If a GET_PARAMETER request contains other parameters than specified here, the MCE shall ignore these parameters. 
In case the request contains only unspecified parameters the request shall be considered as a request with an empty 
body.An empty body is allowed for RTSP keep alive. 

The UE may also set the position parameter (ex. to jump to a bookmark position within a video) by sending the RTSP 
SET_PARAMETER message. Any other parameter that is used in SET_PARAMETER request will be rejected by the 
MCE. 

7.1 .1 .5 Handling of media events 

Upon the reception of the RTSP ANNOUNCE with the beginning-of-stream, the end-of-stream or the transition 
indication the UE may take relevant actions to handle the event (e.g. Terminating session, rewinding the media stream, 
etc.). The UE shall respond with a RTSP 200 OK. 

For BC sessions with trick-play, if the UE receives an RTSP ANNOUNCE request with an end-of-stream indication, 
the UE may initiate a session modification procedure in order to go back to a normal BC session in multicast mode or 
may alternatively take other actions (e.g. rewind, pause, terminate session, etc.). 

If the UE receives an RTSP ANNOUNCE request with a transition indication, the UE may send an RTSP 
GET_PARAMETER with parameter scales in order to have the latest valid scale values. 

If the UE does not understand any of the headers or the notice-code value in the ANNOUNCE request, it simply shall 
ignore the request. 
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7.1 .2 Procedure for content control (Method 2) 

7.1.2.1 Introduction 

After CoD session setup, RTSP as defined in RFC 2326 [8] is used to control media delivery. It includes media setup, 
media control and media teardown. RTSP header fields shall conform to TS 102 034 [3], clause 6.3.2. 

The UE shall support the following RTSP methods: 

• DESCRIBE (UE to MCF). 

• SETUP (UE to MCF). 

• PLAY (UE to MCF). 

• PAUSE (UE to MCF). 

• TEARDOWN (UE to MCF). 

• ANNOUNCE (MCF to UE). 

For transport parameters, the ones conveyed over SIP shall always take precedence over the ones conveyed over RTSP. 

7.1 .2.2 Media description procedure 

If UE did not get content delivery description information (from the SSF or from the SCF/MCF during the SIP session 
initiation), it shall request description of the media via the DESCRIBE message. The RTSP URL to send the 
DESCRIBE message to is retrieved from the SSF data or from the MCF during the SIP session initiation. 

If a domain address is used in the RTSP URL the UE shall not perform DNS lookup. The IP header for the RTSP 
DESCRIBE message shall be set to the IP address from the connection line ("c=") in the SDP answer and the port from 
the media line ("Tn="). 

• The RTSP URL shall be set to the value retrieved from the SDP h-uri attribute in the case of an absolute URL 
If the value of h-url is a relative URI that is in the form of a media path, then the RTSP absolute URL is 
constructed by the UE using the SDP IP Address (from c-line) and port (from m-line) as the base followed by 
h-uri value for the media path. 

(e.g.rtsp://10.5.1.72:22554/rV3/823527). 

NOTE: The UE does not perform DNS lookup in order to avoid misaligning the information conveyed in the 
SDP. 

The UE shall include an Accept header in the request with "application/sdp" and "text/xml". 

7.1 .2.3 Media setup procedure 

On sending a SETUP request, the UE shall populate the header fields as follows: 

RTSP URL header shall be set to the a=control parameter if present in the answer to the DESCRIBE sent by 
the MCF. If not present, RTSP URL shall be set to the corresponding media RTSP URL which has been 
obtained from the SSF data, or from the CoD session initiation. If a domain address is used in the RTSP URL 
the UE shall not perform DNS lookup. The IP header for the RTSP SETUP message shall be set to the IP 
address from the connection hne ("c=") in the SDP answer and the port from the media line ("m="). 

CSeq header shall be generated by the UE. 

On receiving a SIP 200 OK response to the SETUP request, the UE shall retrieve and store the Session header for 
issuing the PLAY request later. 

7.1 .2.4 Media playback initiation procedure 

After SETUP request has been acknowledged as successful, UE shall start the playback of the content by sending an 
RTSP PLAY request. 
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The UE shall populate the header fields as foUows: 

RTSP URL header shall be set to the a=controI parameter if present in the answer to the DESCRIBE sent by 
the MCF. If not present, RTSP URL shall be set to the corresponding media RTSP URL which has been 
obtained from the SSF data, or from the CoD session initiation. If a domain address is used in the RTSP URL 
the UE shall not perform DNS lookup. The IP header for the RTSP SETUP message shall be set to the IP 
address from the connection line ("c=") in the SDP answer and the port from the media hne ("m="). 

CSeq header shall be generated by the UE. 

Session header shall be set to the same value as that in the SETUP request. 

If Range header was present in the DESCRIBE response, then the UE shall use it. Otherwise, the UE may 
include a Range header. If Range header is not sent by the UE, the stream will play from the beginning. 

7.1 .2.5 Media playback modification procedure 

Upon a request to modify playback the UE shall send an RTSP PLAY message with a request to modify the position, 
speed and/or direction of playback. The UE changes the direction and/or speed of playback by including a Scale 
header or change the position of playback by including a Range header. 

The UE shall populate the header fields conforming to clause 7.1.2.4 with the following additions: 

• Range header is optional. 

• Scale header is optional: it is set as follows: 

1 indicates normal play. 

If not 1, the value corresponds to the rate with respect to normal viewing rate. 
A negative value indicates reverse direction. 
If the request is to pause playback, the UE shall send an RTSP PAUSE message. 
On sending a PAUSE request, the UE shall populate the header fields as foUows: 

RTSP URL header shall be set to the same value as that in the previous PLAY request. 
CSeq header shall be set to the same value as that in the previous PLAY request. 
Session header shall be set to the same value as that in the PLAY request. 

7.1 .2.6 Media teardown procedure 

On sending TEARDOWN request, the UE shall populate the header fields as follows: 

RTSP URL header shall be set to the a=control parameter if present in the answer to the DESCRIBE sent by 
the MCF. If not present, RTSP URL shall be set to the corresponding media RTSP URL which has been 
obtained from the SSF data, or from the CoD session initiation. If a domain address is used in the RTSP URL 
the UE shall not perform DNS lookup. The IP header for the RTSP SETUP message shall be set to the IP 
address from the connection Une ("c=") in the SDP answer and the port from the media Une ("ni="). 

CSeq header shall be generated by the UE. 

Session header shall be set to the same value as that in the SETUP request. 

7.1 .2.7 Handling of media events 

Upon the reception of the RTSP ANNOUNCE with the beginning-of-stream, the end-of-stream or the transition 
indication the UE may take relevant actions to handle the event (e.g. Terminating session, rewinding the media stream 
etc.). The UE shall respond with a RTSP 200 OK. 
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For BC sessions with trick-play, if the UE receives an RTSP ANNOUNCE request with an end-of-stream indication, 
the UE may initiate a session modification procedure in order to go back to a normal BC session in multicast mode or 
may alternatively take other actions (e.g. rewind, pause, terminate session, etc.). 

If the UE receives an RTSP ANNOUNCE request with a transition indication, the UE may send a RTSP 
GET_PARAMETER with parameter scales in order to have the latest valid scale values. 

If the UE does not understand any of the headers or the notice-code value in the ANNOUNCE request, it simply shall 
ignore the request. 

7.1 .3 Procedures for Content Switch within a CoD Contentlist 

Upon a request for a content switch the UE shall send an RTSP PLAY message to the MCF using the contentlist 
information received in the SDP. If the UE confirms that the UE and the media server support the "3gpp-switch" feature 
in the session initiation procedure as described in clauses 5.1.16.1 and 5.4.11.1, the UE shall populate the header fields 

as follows: 

• RTSP URL header shall be set to the value received from MF during CoD session initiation. 

• Switch-Stream header shall be set by UE: 

"old-stream" attribute shall be set to RTSP URL of the media stream that is current watchingly being 
watched. 

"new-stream" attribute shall be set to RTSP URL of the new media stream that user wants to switch to. 

EXAMPLE: Switch-Stream:old= rtsp://10.5. 1 .72:22554yTV3/823527; new= 
rtsp://10.5.1.72:22554/TV3/823528). 

NOTE: The syntax of Switch-Stream header is specified in TS 26 234 [49], clause 5.5.4.2. 

7.2 Media Control Function (IVICF) 

7.2.1 Procedures for RTSP playback control (IVIethod 1 ) 

7.2.1.1 Introduction 

The MCF shall support the following RTSP methods for RTSP playback control: 

• PLAY (UE to MCF). 

• PAUSE (UE to MCF). 

• GET_PARAMETER (UE to MCF). 

• SET_PARAMETER (UE to MCF). 

• ANNOUNCE (MCF to UE). 

• OPTION (UE to MCF). 

All other methods that the MCF does not support will result in "405 Method not allowed" reply from the MCF. 
The methods shall use the same session id as specified in the SDP h-session attribute. 

7.2.1 .2 Media Playback Initiation Procedure 

Upon successful RTSP PLAY request the MCF responds with a RTSP 200 OK message except for the cases as follows: 

• If the requested content is not ready for playing, the MCF shall reply with an RTSP error code 404 Not Found. 
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The contents of the RTSP 200 OK response shall be as follows: 

• CSeq shall be set to the same value as that in the request. 

• Date header may be generated by the MCF. It represents the date and time at which the message was 
originated. 

• RTP-Info header may be generated by the MCF when the media packets are transported over the RTF layer. It 
indicates the RTF-specific parameters. The parameters url and rtptime shall be present. The parameter seq is 
recommended to be present. For non-MFEG2TS streams, the UE uses the parameter rtptime to calculate the 
mapping of RTF timestamp to NFT, and the UE may also use the parameter rtptime for inter-media 
synchronization. 

7.2.1 .3 Media playback modification procedure 

Upon successful RTSF FLAY or FAUSE request the MCF responds with a RTSF 200 OK message. 

The contents of the RTSP 200 OK response shall be as follows: 

CSeq shall be set to the same value as that in the request. 

Date header may be generated by the MCF. It represents the date and time at which the message was 
originated. 

RTP-lnfo header may be generated by the MCF when the media packets are transported over the RTF layer. It 
indicates the RTF-specific parameters. The parameters url and rtptime shall be present. The parameter seq is 
recommended to be present. For non-MPEG2TS streams, the UE uses the parameter rtptime to calculate the 
mapping of RTF timestamp to NFT, and the UE may also use the parameter rtptime for inter-media 
synchronization. 

7.2.1 .4 Media playback information retrieval and setting procedure 

Upon successful RTSP GET_PARAMETER or SET_PARAMETER request the MCF responds with a RTSF 200 OK 
message with the requested values or with the successful setting of a parameter. 

7.2.1 .5 Handling of media events 

Upon receipt of the beginning-of- stream or the end-of-stream indication from MDF, MCF may send an RTSF 
ANNOUNCE to the UE with an indication that the beginning-of-stream or the end-of-stream has been reached. 

Upon reception of the indication from the MDF that there is a transition in the media characteristics, MCF shall send a 
RTSP ANNOUNCE to the UE with an indication that transition has occurred. The transition of the media 
characteristics relate to the change in the available playback scales or the current speed of playback. The transition 
occurs when MDF has a playlist which contains content with playback restrictions. The Range header shall be included 
to indicate the current position where the transition has taken place. The Scale header shall be included if the value has 
changed from a previously scale value. 

The "Notice" header shall be included with the notice code value set to "2104 Start-of-Stream Reached", "2101 End-of- 
Stream Reached" or "2103 Transition". 

NOTE: The header and code are based draft-stiemerling-rtsp-announce-01 [i.lO]. The use of other event types is 
outside the scope of the present document. 

7.2.2 Procedure for content control (Method 2) 

The MCF shall act as a media server as defined in RFC 2326 [8]. RTSP header fields shall conform to 

TS 102 034 [3], clause 6.3.2. The MCF shall not redirect the RTSF methods using either the REDIRECT method or 

Redirection status code (3xx). 
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NOTE: It is recommended that the MCF does not perform redirection to avoid misaligning the information 

conveyed in the SDP. The problem occurs if the redirected URL differs from the ones conveyed in the 
SDP connection and media line is that SIP is used for opening proxies and firewalls for the content 
control and the content delivery paths. 

For transport parameters, the ones conveyed over SIP shall always take precedence over the ones conveyed over RTSP. 

7.2.2.1 Introduction 

After CoD session setup, RTSP as defined in RFC 2326 [8] is used to control media deUvery. It includes media setup, 
media control and media teardown. RTSP header fields shall conform to TS 102 034 [3], clause 6.3.2. 

The MCF shall support the following RTSP methods: 

• DESCRIBE (UE to MCF). 

• SETUP (UE to MCF). 

• PLAY (UE to MCF). 

• PAUSE (UE to MCF). 

• TEARDOWN (UE to MCF). 

• ANNOUNCE (MCF to UE). 

All other methods that the MCF does not support will result in "405 Method not allowed" reply from the MCF. 

7.2.2.2 Media description procedure 

Upon successful RTSP DESCRIBE request the MCF responds with a RTSP 200 OK message. 
The DESCRIBE response sent by the MCF shall have: 

• Content-type header set to "application/sdp"; or 

• Content-type header set to "text/xml" and Content-encoding set to "utf8", conforming to TS 102 034 [3], 
clause 6.3.1.2. 

7.2.2.3 Media setup procedure 

Upon successful RTSP SETUP request the MCF responds with a RTSP 200 OK message. 
The contents of 200 OK response shall be as follows: 

CSeq shall be set to the same value as that in the SETUP request. 

Date header may be generated by the MCF. It represents the date and time at which the message was 
originated. 

Session header is generated by the MCF. 

Transport header contains the transport parameters selected by the MCF. 

7.2.2.4 Media playback initiationcontrol procedure 

Upon successful RTSP PLAY request the MCF responds with a RTSP 200 OK message. 
The contents of the RTSP 200 OK response shall be as follows: 

CSeq shall be set to the same value as that in the request. 

Date header may be generated by the MCF. It represents the date and time at which the message was 
originated. 
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RTP-Info header may be generated by the MCF when the media packets are transported over the RTP layer. It 
indicates the RTP-specific parameters. The parameters url and rtptime shall be present. The parameter seq is 
recommended to be present. For non-MPEG2TS streams, the UE uses the parameter rtptime to calculate the 
mapping of RTP timestamp to NPT, and the UE may also use the parameter rtptime for inter-media 
synchronization. 

7.2.2.5 Media playback modification procedure 

Upon successful RTSP control (PLAY, PAUSE) request the MCF responds with a RTSP 200 OK message. 
The contents of the RTSP 200 OK response shall be as follows: 

CSeq shall be set to the same value as that in the request. 

Date header may be generated by the MCF. It represents the date and time at which the message was 
originated. 

RTP-Info header may be generated by the MCF when the media packets are transported over the RTP layer. It 
indicates the RTP-specific parameters. The parameters url and rtptime shall be present. The parameter seq is 
recommended to be present. For non-MPEG2TS streams, the UE uses the parameter rtptime to calculate the 
mapping of RTP timestamp to NPT, and the UE may also use the parameter rtptime for inter-media 
synchronization. 

7.2.2.6 Media teardown procedure 

Upon successful RTSP TEARDOWN request the MCF responds with a RTSP 200 OK message. 
The contents of 200 OK response shall be as follows: 

CSeq shall be set to the same value as that in the TEARDOWN request. 

7.2.2.7 Handling of media events 

Upon receipt of the beginning-of- stream or the end-of-stream indication from MDF, MCF shall send an RTSP 
ANNOUNCE to the UE with an indication that the beginning-of-stream or the end-of-stream has been reached. 

Upon reception of the indication from the MDF that there is a transition in the media characteristics, MCF shall may 
send a RTSP ANNOUNCE to the UE with an indication that transition has occurred. The transition of the media 
characteristics relate to the change in the available playback scales or the current speed of playback. The transition 
occurs when MDF has a playlist which contains content with playback restrictions. The Range header shall be included 
to indicate the current position where the transition has taken place. The Scale header shall be included if the value has 
changed from a previously scale value. 

The "Notice" header shall be included with the notice code value set to "2104 Start-of-Stream Reached","2101 
End-of-Stream Reached" or "2103 Transition". 

NOTE: The header and code are based draft-stiemerling-rtsp-announce-01 [i.lO]. The use of other event types is 
outside scope of release 3. 

7.2.3 Procedures for restricted trick play 

On receiving a request from the user to control the playback (e.g. RTSP PLAY, PAUSE, etc.) which specified in 
clause 7.1, the MCF shall examine the request to see whether the playback operation is permitted based on the restricted 
trick play pohcy. If the requested playback operation is forbidden by the policy, for example, the user tries to fast 
forward when an advertisement is showing, the MCF shall disable the request and respond with a RTSP "405 Method 
Not Allowed" message. 

7.2.4 Procedures for inter-destination media synchronization 

If RTSP method 2 is used, before the MCF sends a reply to the SC to a DESCRIBE method it shall use the assigned 
SSRC value to the media stream (see clause 5.4.10.1). 
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NOTE: The text in clauses 7. 1 .2. 1 and 7.1 .2.2 regarding media description procedure applies here. 
The MCF shall include in the SDP it sends to the SC: 

• a=ssrc:<ssrc-id> <attribute>:<value> as specified in [46]. 

• a=rtcp:port [nettype space addrtype space connection-address] as specified in [47]. 

• a=rtcp-xr: grp-sync, sync-group=<SyncGroupld>, see clause W.2. 

If an SSRC conflict occurs at the transport level, and the MF has to assign a new SSRC value, the MCF shall send an 
RTSP announce to the SC containing the new SSRC value as part of the modified SDP. 

7.2.5 Procedures for Content Switch within a CoD Contentlist 

Upon successful RTSP PLAY request with a Switch-Stream header the MCF responds with a RTSP 200 OK message 
and replace the old media stream with the new media stream except for the cases as follows: 

• If the requested content is not ready for playing, the MCF shall reply with an RTSP error code 404 Not Found. 

• If the requested new media stream is not in the playhst, the MCF shall reply with an RTSP error code 406 Not 
Acceptable 

The contents of the RTSP 200 OK response shall be as described in clause 7.2.1.2 for method 1 or clause 7.2.2.4 for 
method 2. 

7.2.6 Procedure for PlayBack following Session Transfer 

Following a successful session transfer, the transferee UE can use the IPTV Content Marker received during the session 
transfer procedures to view the content using any of the methods in clauses 7.2. 

7.2.7 Playlist handling when end of stream is reached 

For CoD and a UE-owned play list (CoD content list), when a content that is currently being streamed terminates, the 
MCF sends to the UE an RTSP ANNOUNCE message with an indication as per [i.9] to indicate End-of Stream reached, 
2101. 

7.2.8 Procedures for trick play during playlist 

Upon reception of an RTSP trick play while streaming a content belonging to a playlist, the MCF translates/maps 
incoming RTSP commands to the current IPTV content item played out. 

7.3 Synchronization Client (SC) 

7.3.1 Procedures for inter-destination media synchronization 

If RTSP method 2 is used, i.e. because the SC did not receive the synchronization information from the MCF via the 
procedure in clause 5.4.10.1, the SC shall check the SDP for the SSRC identifier and rtcp-parameter containing the 
MSAS address. It shall use the RTCP address and port number given in the SDP using the rtcp-attribute and not an 
RTCP port number specified in the reply to the RTSP SETUP message. 

When an SSRC conflict occurs at the transport level, the SC shall be prepared to receive an RTSP ANNOUNCE 
containing a new SSRC value. 
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8 Procedures using IGMP/MLD for IMS-based IPTV 
8.1 User Equipment (UE) 

If IPv4 is used for the transport, the UE shall support IGMPv3 as described in RFC 3376 [28]. 

If IPv6 is used for the transport, the UE shall support MLDv2 as described in RFC 3810 [29]. 

Backward compatibility rules between the UE and the Transport Fvmction have to be done conforming to 
RFC 3376 [28], clause 7 and RFC 3810 [29], clause 8. 

8.1 .1 Procedure for service selection 

8.1 .1 .1 Procedure to start receiving service selection information 

When the UE wishes to receive service selection information from the SSF in multicast mode, it shall send an IGMPv3 
unsolicited Membership Report or a MLDv2 Multicast Listener Report Message to the Access Node as specified in 

RFC 3376 [28] and RFC 3810 [29]. 

The IGMPv3/MLDv2 request shall be populated as follows: 

• the type shall be set to 0x22 "v3 Membership Report" for IGMPv3 or to 143 "Version 2 Multicast Listener 
Report" for MLDv2; 

• for IGMPv3, the value of "Number of Group Records" is set to the number of group records present in the 
request. For MLDv2, the value of "Number of Multicast Address Records" is set to the number of multicast 
address records present in the request; 

• the Group/Multicast Address Records shall be set as follows: 

"Multicast Address" shall be set to the "Push@MulticastAddress" as specified in the XML document 
sent by the SDF. 

If one or more "Push@SourceAddress" elements are present in the XML document sent by the SDF, 
then: 

"Record Type" shall be set to ALLOW_NEW_SOURCES with INCLUDE filter mode: 

the value of "Number of Sources" is set to the number of source addresses present in the 
group record, i.e. number of "Push@SourceAddress" elements; 

the "Source Address" fields shall be set to the "Push@SourceAddress" elements. 

When no "Push@SourceAddress" element is present in the XML document sent by the SDF (i.e. source 
address filtering is not used): 

"Record Type" shall be set to CHANGE_TO_EXCLUDE_MODE with no "Source Address" fields. 

The case when the UE has to use IGMP v2 for compatibihty reason (i.e. the network does not support IGMPv3), the UE 
shall send v2 Membership report, set as follow: 

the type shall be set to 0x16 "v2 Membership Report"; 

the Max response time shall be set to 0; 

the Group Address shall be set to the "Push@MulticastAddress" element as specified in the XML document 
sent by the SDF. 

To cover the possibihty of the initial Membership Report or Multicast Listener Report being lost or damaged, the UE 
may resend the request once or twice after short delays. If the UE does not receive service selection data as a result of 
sending these requests, it shall assume that the data are not available and shall stop attempting to join the multicast 
group. 
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8.1 .1 .2 Procedure to stop receiving service selection information 

When the UE wants to stop receiving service selection information from an SSF in muhicast mode, it shall send an 
IGMP v3 Membership Report Message or MLD v2 Multicast Listener Report Message for leaving a multicast group. 

The IGMPv3/MLDv2 request shall be populated as follows: 

• the type shall be set to 0x22 "v3 Membership Report" for IGMPvB or to 143 "Version 2 Multicast Listener 
Report" for MLDv2; 

• for lGMPv3, the value of "Number of Group Records" is set to the number of group records present in the 
request. For MLDv2, the value of "Number of Multicast Address Records" is set to the number of multicast 
address records present in the request; 

• the Group/Multicast Address Records shall be set as follows: 

"Multicast Address" shall be set to the "Push@MulticastAddress" as specified in the XML document 
sent by the SDF related to the service selection information that the user does not want to receive 
anymore. 

When one or more "Source Address" fields were set in the Join Operation, the same source address list 
shall be excluded from the listening interface: The "Record Type" shall be set to 

"BLOCK_OLD_SOURCES" and the "Source Address" fields shall be set to the source Ust being filtered. 

If no "Source Address" fields were set in the Join Operation, The "Record Type" shall be set to 
"CHANGE_TO_E^CLUDE_MODE" with an empty source list. 

When the UE has to use IGMP v2 for compatibility reason (i.e. the network does not support IGMPv3), the UE shall 
send v2 Leave, set as follow: 

the type shall be set to 0x17 "Leave Group"; 

the Max response time shall be set to 0; 

the Group Address shall be set to the "Push@MulticastAddress" element as specified in the XML document 
sent by the SDF. 



8.1 .2 Procedure for BC service 



8.1 .2.1 Procedure for joining a BC service 

After the BC session initiation procedure, when the UE wishes to join a particular BC service, an IGMP unsolicited v3 
Membership Report or a MLD v2 Multicast Listener Report Message to the Access Node as specified in RFC 3376 [28] 

and RFC 3810 [29]. 

The IGMPv3/MLDv2 request shall be populated as follows: 

• the type shall be set to 0x22 "v3 Membership Report" for IGMPv3 or to 143 "Version 2 Multicast Listener 

Report" for MLDv2; 

• for IGMPv3, the value of "Number of Group Records" is set to the number of group records present in the 
request. For MLDv2, the value of "Number of Multicast Address Records" is set to the number of multicast 
address records present in the request; 

• the Group/Multicast Address Records shall be set as follows: 

"Multicast Address", as obtained from the SSF, shall be set to one of the allowed channels according to 
the session initiation. 
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When one or more source address elements are present in network parameters received during the BC 
session initiation procedure or received from the SSF, then: 

"Record Type" shall be set to ALLOW_NEW_SOURCES with INCLUDE filter mode: 

the value of "Number of Sources" is set to the number of source addresses present in the 
group record; 

the "Source Address" fields shall be set to the source address elements received during the 
BC session initiation procedure or received from the SSF. 

If no source address elements are present in network parameters received during the BC session initiation 
procedure or received from the SSF, (i.e. source address filtering is not used): 

"Record Type" shall be set to CHANGE_TO_EXCLUDE_MODE with no "Source Address" fields. 

When the UE has to use IGMP v2 for compatibility reason (i.e. the network does not support IGMPv3), the UE shall 
send v2 Membership report, set as follow: 

the type shall be set to 0x16 "v2 Membership Report"; 

the Max response time shall be set to 0; 

the Group Address shall be set to the multicast address, as obtained from the SSF. It must be one of the 
allowed channels according to the session initiation. 

To cover the possibility of the initial Membership Report or Multicast Listener Report being lost or damaged, the UE 
may resend the request once or twice after short delays. If after these attempts no BC media received, and an IGMP v3 
Membership Report was sent, the UE shall revert to an IGMP v2 Multicast Listener Report and repeat the above 
procedure. If the UE does not receive BC media data as a result of sending these requests, it shall assume that the data is 
not available and shall stop attempting to join the multicast group. 



8.1 .2.2 Procedure for leaving BC service 

When the UE wants to stops receiving content delivery data from the previously selected BC service, it shall send an 
IGMPvS Membership Report Message or MLDv2 Multicast Listener Report Message for leaving a multicast group. 

The IGMPv3/MLDv2 request shall be populated as follows: 

• the type shall be set to 0x22 "v3 Membership Report" forlGMPvB or to 143 "Version 2 Multicast Listener 
Report" for MLDv2; 

• for IGMPv3, the value of "Number of Group Records" is set to the number of group records present in the 
request. For MLDv2, the value of "Number of Multicast Address Records" is set to the number of multicast 

address records present in the request; 

• the Group/Multicast Address Records shall be set as follows: 

"Multicast Address" shall be set to the multicast address of the BC service that the user does not want to 
receive anymore. 

When one or more "Source Address" fields were set in the Join Operation, the same source address list 
shall be excluded from the listening interface: The "Record Type" shall be set to 

"BLOCK_OLD_SOURCES" and the "Source Address" fields shall be set to the source Ust being filtered. 

If no "Source Address" fields were set in the Join Operation, The "Record Type" shall be set to 
"CHANGE_TO_lNCLUDE_MODE" with an empty source list. 

The case when the UE has to use IGMP v2 for compatibiUty reason (i.e. the network does not support IGMPv3), the UE 
shall send v2 Leave, set as follow: 

the type shall be set to 0x17 "Leave Group"; 

the Max response time shall be set to 0; 

the Group Address shall be set to the multicast address of the BC service the UE wants to leave. 
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8.1 .3 Procedure for Notification service using multicast media patli 

When the notification service is consumed together with the related BC service, the notification service is described as a 

separate service fi^om the related BC. In this case, an extension to the BC service mechanism, through the inclusion of a 
"Network Generated Notification" indicator, is used to identify such a notification service. 

The UE shall join a notification service hke Procedure for joining a BC service in clause 8.1.2.1, the Group/Multicast 
Address Records and the Group Address shall be set to the notification multicast address. 

The UE shall leave a notification service like Procedure for leaving a BC service in clause 8.1.2.2, the Group/Multicast 
Address Records and the Group Address shall also be set to the notification multicast address. 

8.2 Transport Functions 

For IPv4 multicast IPTV service distribution, the network transport fimctions shall support minimally IGMPv2 or 
higher. The use of IGMPv3 is recommended, in which case the backwards compatibiUty rules of RFC 3376 [28], 

clause 7 shall apply. 

For IPv6 multicast IPTV service distribution, the network transport functions shall support minimally MLDvl or 
higher. The use of MLDv2 is recommended, in which case the backwards compatibiUty rules of RFC 3810 [29], 
clause 8 shall apply. 

8.2.1 Receiving IGIVIP/IVILD request corresponding to a join operation 

When receiving an IGMP/MLD request corresponding to a join, the ECF/EFF shall check, based on traffic policies, 
whether the sender of the request is allowed to join the targeted multicast group. If the multicast group is not allowed 
the ECF/EFF shall ignore the UE request. If the multicast group is allowed, the ECF/EFF may also check whether the 
resource level specified in the installed policy matches the resource level required by the requested multicast group. In 
case of a mismatch, the ECF/EFF node may request a new policy by querying the RACS. If fails no new policy is 
received or the new policy still does not match the request, the ECF/EFF shall ignore the UE request. 

Traffic policies may be pre-configured in the ECF/EFF, received from the RACS when the UE attaches to the network 
(i.e. RACS push model), received from the RACS as a result of an IMS session being established (i.e. RACS push 
model) or received from the RACS in response to a query from the ECF/EFF (i.e. RACS pull model). Information 
received from the RACS takes precedence over pre-configured policies. Traffic policies supporting the decisions to 
forward traffic and traffic policies supporting admission control may be received using the same or different means. 
Whether the ECF/EFF queries the RACS depend on local policy rules and on the targeted multicast group. The 
ECF/EFF queries the RACS, by sending a DIAMETER CCR conamand as defined in TS 183 060 [38]. 

If the targeted multicast group is allowed and the resource reservation procedure is successful the ECF/EFF shall 
register the UE IP address as member of this multicast group and begin to forward content delivery data to the UE, 
when available. 

If the ECF/EFF does not receive content delivery data from this multicast group yet, it shall subscribe to it. 

8.2.2 Receiving IGIVIP/IVILD request corresponding to a leave operation 

When Receiving IGMP/MLD request corresponding to a leave operation, the ECF/EFF shall stop forwarding data to the 
UE corresponding to the multicast group indicated in the Leave operation and delete the subscription of the UE IP 
address to this group. If pull model is used, the ECF/EFF shall inform the RACS of the Leave operation to make the 
resources available to other services by sending a DIAMETER CCR command as defined in TS 183 060 [38]. 



9 Procedures using DVBSTP for IMS-based IPTV 

This clause applies when using DVB-IPTV multicast deUvery for service and content guide discovery. 
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9.1 User Equipment (UE) 

9.1 .1 Procedure for service selection 

9.1 .1 .1 Request of DVB service discovery and selection data 

In the DVB push model of multicast dehvery of DVB SD&S data, the UE shall subscribe to the multicast DVBSTP 
streams identified within the response from the SDF. Refer to clause 8 for multicast connection mechanism. 

9.1 .1 .2 Request of DVB broadband content guide 

In the DVB push model of multicast delivery of a DVB BCG data, the UE shall subscribe-to the multicast DVBSTP 
streams identified within the response from the SDF or within the Service Selection information returned by the SSF. 
Refer to clause 8 for multicast coimection mechanism. 

9.1 .1 .3 Use of service selection information 

The UE uses service selection information as defined in clause 6.1.1.5. 

9.2 Service Selection Function (SSF) 

9.2.1 Procedure for service selection 

9.2.1 .1 Delivery of DVB service discovery and selection data 

In the DVB push model of multicast delivery of DVB SD&S data, the DVBSTP protocol shall be used conforming to 
TS 102 034 [3], clause 5.4.1. 

9.2.1 .2 Delivery of DVB broadband content guide 

In the DVB push model of multicast delivery of a DVB BCG data, the DVBSTP protocol shall be used conforming to 
TS 102 539 [13], clause 4.1.2.2.1. 

1 Procedures using FLUTE for IMS-based IPTV 

NOTE: This clause appUes when using OMA BCAST multicast deUvery for service provider and guide 
discovery. 

10.1 User Equipment (UE) 
10.1.1 Procedure for service selection 

1 0.1 .1 .1 Request of OMA BCAST service discovery and selection data 

In the OMA BCAST push model of multicast delivery of OMA BCAST ESG provider discovery data, the UE shall 
subscribe to the FLUTE streams identified within the response from the SDF, conforming to clause 9.2 in 
TS 102 471 [4] and clause 6 of TS 102 472 [5]. 
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1 0. 1 . 1 .2 Request of OM A BCAST service guide 

In the OMA BCAST push model of muhicast delivery of an OMA BCAST ESG, the UE shall subscribe to the FLUTE 
streams identified within the response from SDF or within the Service Selection information returned by the SSF, 
conforming to TS 102 471 [4], clause 8.1, OMA-TS BCAST_DVB_Adaptation-Vl_0 [6], clause 6.3.5 and 
OMA-TS-BCAST_Service_Guide-Vl_0, clause 5.4 [5]. 

1 0.1 .1 .3 Use of service selection information 

The UE uses service selection information as defined in clause 6.1.1.5. 

10.1.2 Procedure for multicast download 
1 0.1 .2.1 Request for multicast download 

In the optionally supported multicast content delivery for content download, the UE shall subscribe to the FLUTE 
streams identified within the service request response, conforming to CDS in TS 102 034 [3] conform to clause 10 
there. 

NOTE: The details about acquiring and initiating multicast download are not specified in this specification as 
indicated in clause 5.1.18.2. The procedures need to conform to CDS in TS 102 034 [3] and will be 
similar to the procedures for unicast download (clause 5.1.18.1). 

10.2 Service Selection Function (SSF) 
1 0.2. 1 Procedure for service selection 

1 0.2.1 .1 Delivery of OMA BCAST service discovery and selection data 

In the OMA BCAST push model of multicast dehvery of OMA BCAST ESG provider discovery data, the FLUTE 
protocol shall be used, conforming to TS 102 471 [4], clause 9.2 and OMA-TS-BCAST_DVB_Adaptation-Vl_0, 
clause 6.3.5 [6]. 

1 0.2.1 .2 Delivery of OMA BCAST service guide 

In the OMA BCAST push model of multicast dehvery of an OMA BCAST ESG, the FLUTE protocol shall be used, 
conforming to TS 102 471 [4], clause 8.1, OMA-TS-BCAST_DVB_Adaptation-Vl_0 [6], clause 6.3.5 and OMA-TS- 
BCAST_Service_Guide-Vl_0 [5], clause 5.4. 

10.3 Media Delivery Function (MDF) 
1 0.3.1 Procedure for multicast download 

If the optional multicast content download is used for the PushCOD it shall be comprised of parts that further specify 
how FLUTE is used in TS 102 034 [3] (as in clause 10 Content Download Service). The purpose of file delivery is to 
dehver content items in files. A file may contain any type of data (e.g. AudioA^ideo file. Binary data, still images. 
Text). 
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1 1 Procedures using UDP/RTP/RTCP for IMS-based 
IPTV 

The IPTV content is transported over the IP network. In order to do so, several encapsulation are possible: 

• MPEG2TS: the content is encapsulated into MPEG2TS packets: 

MPEG2TS over UDP: the MPEG2TS packets are directly transported over the UDP layer. 
MPEG2TS over RTP: the MPEG2TS packets are transported over the RTP layer. 

• Direct RTP: no MPEG2TS encapsulation is used, the Elementary streams are directly transported over the 
RTP layer. 

1 1.1 User Equipment (UE) 

11.1.1 Procedure for real-time transport 

The UE shall support at least one of the following transport technologies: 

• MPEG2TS encapsulation. 

• Direct RTP transport. 

11.1.1.1 Transport using MPEG2TS 

The UE may be able to receive the content encapsulated in MPEG2TS packets. 
When using the MPEG2TS encapsulation technology, the UE shall support both: 

• MPEG2TS over UDP conforming to TS 102 034 [3], clause 7.1.2. 

• MPEG2TS over RTP conforming to TS 102 034 [3], clause 7.1.1 excluding clause 7.1.1.1. 

As specified in ES 283 003 [20], it is possible to negotiate RTCP bandwidth - and thus to control UE 
receiver report generation - for unicast IPTV services during SIP session setup. 

NOTE 1 : Handling of RTCP Receiver reports for BC services is out of scope of the present document. 

NOTE 2: The default behaviour in the case that - for m-lines indicating RTP/RTCP usage - no RTCP bandwidth 
negotiation is performed, is described in ES 283 003 [20]. 

1 1 . 1 . 1 .2 Transport using direct RTP encapsulation 

The UE may be able to receive the content directly over the RTP layer (e.g. H264 over RTP). 

As specified in ES 283 003 [20], it is possible to negotiate RTCP bandwidth - and thus to control UE receiver report 
generation - for unicast IPTV services during SIP session setup. 

NOTE 1 : Handling of RTCP Receiver reports for BC services is out of scope of the present document. 

NOTE 2: The default behaviour in the case that - for m-lines indicating RTP/RTCP usage - no RTCP bandwidth 
negotiation is performed, is described in ES 283 003 [20]. 

1 1 .1 .2 ProcecJure for real-time transport eError correction 

The UE may support a transport error correction mechanism. 
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1 1 .1 .2.1 Unidirectional transport error correction 

When unidirectional transport error correction is used, the UE shall be able to receive an appUcation Layer FEC, 
conforming to TS 102 034 [3], annex E. 

NOTE: Only the base layer of the DVB-IP AL-FEC is supported in the present document, the enhancement layer 
support is out of scope. 

1 1 .2 Media Delivery Function (IVIDF) 

1 1 .2.1 Procedure for real-time transport 

The MDF shall send the content using one of the following transport technologies: 

• MPEG2TS encapsulation. 

• Direct RTF transport. 

1 1 .2.1 .1 Transport using MPEG2TS 

The MDF may be able to send the content encapsulated into MPEG2-TS.ln that case, one of the following shall be 
used: 

• The transport of the IPTV content within MPEG2TS layer over RTF shall be done conforming to 
TS 102 034 [3], clause 7.1.1. 

• The transport of the IFTV content within MFEG2TS layer over UDF shall be done conforming to 
TS 102 034 [3], clause 7.1.2. 

1 1 .2.1 .2 Transport using direct RTP encapsulation 

The MDF may be able to send the content directly over the RTP layer (e.g. H264 over RTF). 

1 1 .2.2 Procedure for real-time transport error correction 

The MDF may support a transport error correction mechanism. 

1 1 .2.2.1 Unidirectional transport error correction 

For unidirectional transport error correction the MDF shall use an appUcation Layer FEC mechanism, conforming to 
TS 102 034 [3], annex E. 

NOTE: Only the base layer of the DVB-IP AL-FEC is supported in the present document, the enhancement layer 
support is out of scope. 

1 1 .2.3 Procedures for inter-destination media synchronization 

The use of inter-destination media synchronization requires the MDF to support transport using either MPEG2TS layer 
over RTP, see clause 11.2.1.1., or direct RTP encapsulation, see clause 11.2.1.2. 

1 1 .3 Synchronization Client (SC) 
11 .3.1 Procedure for real-time transport 

The SC shall support at least one of the following transport technologies: 

• MPEG2TS encapsulation. 
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• Direct RTP transport. 

11.3.1.1 Transport using MPEG2TS 

The SC may be able to process content that is encapsulated in MPEG2TS packets. 

When using the MPEG2TS encapsulation technology, the SC shall support MPEG2TS over RTP as described in 
clause 11.1.1.1. 

NOTE 1 : The limitation to MPEG2TS over RTP is necessary since RTCP is used. 

NOTE 2: As specified in ES 283 003 [20], it is possible to negotiate RTCP bandwidth - and thus to control SC 
receiver report generation - for unicast IPTV services during SIP session setup. 

The SC shall support RTCP Extensions for Single-Source Multicast Sessions (i.e. BC services) with Unicast 
Feedback [43]. 

1 1 .3.1 .2 Transport using direct RTP encapsulation 

The SC may be able to process content that is transported directly over the RTP layer (e.g. H264 over RTP). 

As specified in ES 283 003 [20], it is possible to negotiate RTCP bandwidth - and thus to control SC receiver report 
generation - for unicast IPTV services during SIP session setup. 

The SC shall support RTCP Extensions for Single-Source Multicast Sessions (i.e. BC services) with Unicast Feedback 
as specified in [43] 

1 1 .3.2 Procedures for inter-destination media synchronization 

The SC shall send RTCP Receiver Reports (RRs) to media-level MSAS address, which is the specified IP address and 
port number in the SDP description or to a pre-configured media-level MSAS address in case of mapping the UE on a 
Transport Processing Function, see clause 4.2.8. 

The SC shall extend the RRs with synchronization status information, using an RTCP eXtended Report (XR), as 
specified in clause W.I. The synchronization status information shall include the SSRC of source, the Packet Received 
NTP timestamp and the Packet Received RTP timestamp. It should include thePacket Presented NTP timestamp 

The SC shall populate the Media Stream Correlation Identifier with the SyncGroupId parameter as specified in 
clause W.I. 

The SC shall be able to receive RTCP reports from the MSAS, on the regular RTCP receive port. 

The SC shall be able to receive RTCP extended Reports (XR) containing synchronization settings instructions, as 
specified in Annex W.l. The RTCP XRs with synchronization settings instructions shall include the SSRC of source, 
and packet arrival time information, specifically the reference Packet Received NTP timestamp and the reference 
Packet Received RTP timestamp receipt time stamp. It should include the reference Packet Presented NTP timestamp. 
These RTCP XRs may be both appended to RTCP Sender Reports (SRs), but may also be received separately. 

NOTE I: Synchronization settings instructions may be interpreted as the synchronization status information of a 
virtual SC to which this SC may try to synchronize. 

The SC shall be NTP synchronized [56]. 

NOTE 2: The quality of the underlying NTP synchronization of SCs is a determining factor in inter-destination 
media synchronization. ITU-T Recommendation G.I 14 [i.8] recommends maximum one-way 
transmission time for an international telephone connection to achieve transparent interactivity. G.114 
contains the following statements: "if delays can be kept below (150 ms), most apphcations, both speech 
and non-speech, will experience essentially transparent interactivity" and "delays above 400 ms are 
unacceptable for general network planning purposes". As the purpose of inter-destination media 
synchronization is typically achieving transparent interactivity (see also TS 181 016 [60] clause A.9.6), 
the ITU-T Recommendation G.I 14 [i.8] is a useful guideline. 

The SC shall not require to receive any RTCP extended Reports (XR) containing synchronization settings instructions. 
The absence of such instructions shall not be taken as a sign that something is wrong. 
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NOTE 3: The SC may not receive synchronization settings instructions because RTCP is normally transported 

using the unreliable UDP protocol. The SC may also not receive any instructions if it is the most delayed 
SC in its synchronization group, if it is the only member of its group or if buffering is carried out in the 
ECF/EFF, see clause 11.5.1. 

If the SC is co-located with the MSAS, then the exchange of synchronization status information and synchronization 
settings instructions is internal to the functional entity in which they reside. 

NOTE 4: An example of co-located SCh-MSAS functionality is when UEs exchange synchronization status 

information and synchronization settings instructions over an existing direct communication channel, see 
clause A.5.2.3. 

NOTE 5: The algorithm that is used by the SC to synchronize the media based on the synchronization settings 
instructions is a vendor implementation decision. See [i.6] for an overview of techniques. 



1 1 .4 Media Synchronization Application Server (IVISAS) 
11 .4.1 Procedures for inter-destination media synclnronization 

In the case of synchronization for a broadcast stream, the MSAS shall function as a Feedback Target, specified in [43]. 
Before forwarding RTCP Receiver Reports to the appropriate MF, the MSAS shall read and remove RTCP extended 

Reports containing synchronization status information, which are specified in Annex W. The MSAS shall send 
synchronization settings instructions to the SC using RTCP extended Reports, which are specified in Annex W. 

The synchronization settings instructions take the form of RTP timestamps, combined with NTP timestamps. The NTP 
timestamp indicates the clock shared by the synchronization group, the RTP time stamps indicate the expected receipt 
and/or presentation time. The MSAS shall send expected receipt times. It should send expected presentation time 
stamps. 

NOTE 1: Synchronization settings instructions may be interpreted as the synchronization status information of a 
virtual SC to which the addressed SCs may try to synchronize. 

NOTE 2: The algorithm that is used by the MSAS to derive the synchronization settings instructions from the 
received synchronization status information is a vendor implementation decision. See [i.6] for an 
overview of techniques. 

For synchronization of Content on Demand or other unicast streams, the MSAS shall forward RTCP Receiver Reports 
to the appropriate MF. Before forwarding RTCP Receiver Reports, the MSAS shall read and remove RTCP extended 
Reports containing synchronization status information, which are specified in annex W. The MSAS shall forward RTCP 
Sender Reports to the appropriate SC, appending synchronization settings instructions to the SC using RTCP eXtended 
Report. The MSAS may send synchronization settings instructions to the SC using a separate RTCP XR. The RTCP XR 
for sending synchronization settings instructions is specified in annex W. 

In case of synchronization in the presence of functional entities that modify or re-originate media streams (e.g. a 
transcoder or a mixer in an MDF), the MSAS shall function as a Third Party Monitor [44]. It shall be able to receive and 
process synchronization correlation information as specified in clause 11. 6. 2. 

NOTE 3: Synchronization correlation information enables an MSAS to correlate the timing of two related media 
streams. By using NTP time as a reference, the MSAS can determine which RTP timestamp of the one 
media stream corresponds with which RTP timestamp of the other media stream. 

For scalability, the MSAS may consist of multiple entities organized in a hierarchical way. A "proxy" MSAS may 
aggregate synchronization status information of multiple SCs by forwarding only the status information of the most 
delayed SC in a synchronization group to an MSAS that is located hierarchically up the chain. If a "proxy" MSAS 
aggregates information in this manner, it shall keep track of the SCs that are part of the synchronization group, and it 
shall relay synchronization settings instructions to the different SCs. 

NOTE 4: [43] specifies that 'the Feedback Target instances MAY be organized in arbitrary topological structures: 
in parallel, hierarchical, or chained'. Such topological structures can be used for aggregation purposes to 
improve scalability. 



ETSI 



129 



ETSI TS 183 063 V3.5.1 (2011-02) 



11.5 ECF/EFF 

11 .5.1 Procedures for inter-destination media synclironization 

In one mapping of the SC is an adjunct function that may be co-resident with any of the appropriate elements of the 
Transport Processing Function, see clause 4.2.8. If the SC is an adjunct function of the ECF/EFF, then ECF/EFF shall: 

• Send synchronization status information to the MSAS using an RTCP eXtended Report (XR), as specified in 
annex W. 

• Be able to receive RTCP extended Reports (XR) containing synchronization settings instructions, as specified 
in annex W. 

The ECF/EFF may have partial SC functionality, supporting SC functionality in the UE. This reqiures that the SC in the 
ECF/EFF is in the path between the UE and the MSAS used. In this case the ECF/EFF shall be able to: 

• Monitor and possibly adjust synchronization status reports going from UE to MSAS. Reported arrival times 
need to be adjusted for the current buffer time the ECF/EFF has introduced. 

• Determine the arrival time for the indicated stream at the SC in the ECF/EFF. 

• Intercept and carry out synchronization settings instructions. Synchronization settings instructions may or may 
not be forwarded to the SC in the UE. 

NOTE: Combining an SC in a UE with an SC in the ECF/EFF may have advantages for channel changing times 
and synchronization accuracy. When buffering at a UE, channel changing times during the use of a shared 
service session may be quite large if one of the participants is severely lagging behind the others. 
Buffering in the ECF/EFF can reduce channel changing times. This requires the ECF/EFF to pre-buffer 
the channel to which the UE is changing. Furthermore, if buffering is applied in the ECF/EFF, 
measurements from a UE can be used to increase synchronization accuracy. 



1 1 .6 Synchronization Client' (SC) 
1 1 .6.1 Procedure for real-time transport 

Clause 11.3.1 is also applicable to SC. 



1 1 .6.2 Procedures for inter-destination media synclironization 

The SC shall send synchronization correlation information to the MSAS, which acts as a Third Party Monitor [44] with 
respect to the SC. Synchronization correlation information has the following components. 

• RTCP extended Report (XR) related to the incoming media stream. 

• RTCP extended Report (XR) related to the outgoing media stream. 

XR related to the incoming media steam is specified in annex W. The XR contains the SSRC of the incoming media 
stream, the NTP timestamp and the Packet Received RTP timestamp. The Packet Presented RTP timestamp field shall 

be set empty. 

XR related to the outgoing media stream is specified in annex W. The XR contains the SSRC of the outgoing media 
stream, the NTP timestamp and the RTP time stamp. The Packet Presented RTP timestamp field shall be set empty. 



1 2 IPTV user profile schenna 

The IPTV user profile is described by an XML document. This XML document complies with the XML schema 
defined in annex C. 
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Although it is not explicit in the XML schema described in annex C, the IPTV user profile must comprise at least one 
BC profile or CoD profile. 

The "Global Settings" element is set to "optional" in the IPTV user profile. However, in the case where this element 
would not be provided, default values should be used: 

the User Action Recordable Boolean should be assumed to be set to "false"; 

the preferred language value should be assumed to be to one that is globally defined by the service provider 
(hence applicable to all users). 

In the case where the ParentalControlLevel is not provided, its value is assumed to be the default level defined by the 
service provider (hence applicable to all users). 

In the case where the quality definition is not provided, its default value shall be "SD". 



1 3 IPTV service action data schema 

For convenience purposes, each object class of the IPTV service action data is described by a sepiirate XML documents. 
Those XML document comply with the XML schema defined in annex D. 

Although they are defined as optional in the XML schema described for "NPVR items" in annex D, the "BCServiceld", 
"RecordStartDate" and "RecordEndDate" attributes are required in the case where the NPVRContentID attribute does 
not refer to a Programme Id (i.e. an entry in the EPG). 

Bookmark and RecordStartDate attributes shall either take the form of an xs:dateTime type, or be equal to "NOW". 
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Annex A (informative): 

Functional entity relations and example signalling flows of 
IMS based IPTV operations 



A.O Example signalling flows for IPTV services 

Any signalling flow in annex A shall follow procedures implementation details described in procedures clauses 
(clauses from 5 to 1 1). Signalling flows listed in this clause are only informative examples for selected IPTV services. If 
signalling flows for other IPTV services are not explicitly mentioned in annex A then signalling flows should follow 
procedures as described in [2], clause 8. 



A.1 Functional entities relations and overview of the IMS 
based IPTV procedures 



Legend: IMS based IPTV model 
SIP/SDP 
U DP/RTF 
Diameter 




NOTE 1 : This figure represents relationships and protocols between the functional entities at high level. The details 
of corresponding procedures and signalling flows are in the following clauses of this annex. 

NOTE 2: As described in TS 182 027 [2], clause 6.4 and 6.5, Xc and Xd are logical reference points that can be 
decomposed of Dj and possibly Di, Ds or Iz reference points depending on the location of the IVICF or 
MDF. 

Figure A.1 : IMS based IPTV - protocol model with FE relation 



0) First of all it is needed to start or boot a UE (like a set-top-box, PC, mobile or any device with an IPTV 
client) and achieve network attachment to obtain network parameters (like an IP address, P-CSCF 
address, etc.). 

1) After network attachment the UE initiate the IMS registration process with core IMS (as described in 
clause 5.1.1). 
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2) UE will perform IPTV service attachment functions including SIP based service discovery to perform 
SDF tasks (as described in clause 5.1.2). 

3) Then UE is able to initiate the service selection procedures with SSF via Xa (using HTTP over Xa as 
described in clause 6.1.1, using DVBSTP as in clause 9 or FLUTE 10) to receive service selection 
information. 

4) The IMS based IPTV UE needs to know and used received service selection information to establish 
appropriate multimedia session by generating SIP INVITE messages during service initiation procedure 
(over Gm towards home C-CSCF) send via IMS core to SCF. 

NOTE 1 : SIP based request for service initiation (SIP procedures is applicable also for service termination or 

termination) is used for BC service (as in clause 5.1.3), CoD service (as in clause 5.1.4) or for N-PVR 
Service (as in clause 5.1.7). 

NOTE 2: The core IMS is able to initiate resource reservation process for network resources needed by the IPTV 
streams according to the capabilities of the UE. The resource reservation and allocation is performed 
using standardized transport control functions of NGN RACS connected to the core IMS. 



5) to 6) After the successful session initiation, the SCF informs the MCF via core IMS and y2 interface (or UE in 
some case like BC) about identification of selected content from the Media Delivery Function (or 
ECF/EFF in the case of BC services) to initiate start streaming the selected multimedia content (CoD, N- 
PVR). 

7) The UE may control CoD media stream over the Xc (see note 2 for figure A.l) interface (between the UE 
and the MCF) to control media delivery with RTSP protocol (as in clause 7). The UE may control BC 
media stream over the Dj interface (between the UE and the ECF/EFF) to control media delivery with 
IGMP/MLD protocol (as in clause 8). 

8) The MDF performs media delivery over the Xd (see note 2 for figure A. 1) interface is based on UDP/RTP 
stream deUvery and several transport variants (as described in clause 11). 



A.2 Example signalling flows of service discovery 
operation 

A.2.1 Push mode 

This clause describes an example of signalUng flow of the service discovery based on the Push mode. 



UE 




Core IMS 




SDF 









1. REGISTER 



2. 200 OK 



3. Match the iFC 



4. REGISTER 



5. 200 OK 



6. MESSAGE 

7. MESSAGE 



8. 200 OK ^ 

9. 200 OK 



Figure A.2: Service discovery of Pusli mode operation 

1) The UE sends a REGISTER request to the Core IMS. 
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2) Core IMS finishs the registration, and sends the SIP 200 OK to the UE. 

3) Core IMS matches the iFC of the service profile belong to the user, and finds out the SDF that user has 

subscribed. 

4) Core IMS sends the third-party REGISTER request to the SDF. 

5) The SDF acquires the register status of the UE, and sends the SIP 200 OK to the Core IMS. 

6) The SDF sends the Service Attachment Information to the UE by the SIP MESSAGE request. The SDF could 
trigger service discovery logic, and configure the appropriate service attachment information for the user. Here 
the SDF could retrieve the user's location, UE's capability etc from IPTV user profile, for configure the service 
attachment information. 

7) The Core IMS relays the SIP MESSAGE to the UE. 

8) The UE receives the SIP MESSAGE with Service Attachment Information, and sends the SIP 200 OK to the 
SDF. 

9) The Core IMS relays the SIP 200 OK to tiie SDF. 

A.2.2 Pull Mode 

This clause describes an example of signalhng flow of the service discovery based on the Pull mode. 



UE Core IMS SDF 




1. SUBSCRIBE ^ 








2. PSI or iFC 


_^ 5. 200 OK 


3. SUBSCRIBE ^ 


^ 4. 200 OK 


_^ 6. NOTIFY 


_^ 7. NOTIFY 


9. 200 OK ^ 


8. 200 OK ^ 







The UE may retrieve the PSI/address of the SDF based on mechanisms defined in annex I. 
Figure A.3: Service discovery of Pull mode operation 

The UE sends a SUBSCRIBE request to the Core IMS. The SUBSCRIBE could also contain a body to 
carry the UE's capabihties. 

The Core IMS forwards the SUBSCRIBE to the SDF. The Core IMS could forwards the SUBSCRIBE 

based on the PSI or IPC. 

After a successful subscription, the SDF generates a SIP 200 OK in response to the SUBSCRIBE. When 
the SUBSCRIBE carry the UE's capabihties in the message body, the SDF examines and records UE 
capabilities information as part of the IPTV user profile data. 

The Core IMS relays the SIP 200 OK to the UE. 

The SDF generates the NOTIFY for the service attachment information. The SDF could retrieve the UE's 
capabilities to generate the personahzed service attachment information. 

The Core IMS relays the NOTIFY to the UE. 

The UE receives the NOTIFY with the service attachment information, and sends the SIP 200 OK to the 
SDF. 
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9) The Core IMS relays the SIP 200 OK to the SDF. 

A.3 Example signalling flows of CoD operation 
A.3.1 UE-initiated session initiation 

NOTE: As stated in TS 182 027 [2], the SCF may originate requests to the MF without involving the core-IMS. 

A.3.1 .1 Session initiation flows for case of establishing content control 
channel and content delivery channels separately using RTSP 
method 2 

This clause describes an example signalhng flow using RTSP method 2, see clauses 5.4.1.2.2, 7.1.2 and 7.2.2. 
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UE 



content selection 



19. Extract SDP information 



RAGS 



Core-IMS 



1. INVITE 



CoD-SCF 



2. Resource Reservation 



3. INVITE 



4. select CoD-MCF 



5. INVITE 



6. INVITE 



7. 200 OK 



8. 200 OK 



9. 200 OK 



10. Resource Commit 



11. 200 OK 



12. ACK 



13. ACK 



14. ACK 



15. ACK 



16. Establish TCP Connection for RTSP 



17. DESCRIBE 



18. 200 OK 



20. SETUP 



21.200 OK 



22. re-INVITE 



23. Resource Reservation 



24. re-INVITE 



25. re-INVITE 



26. re-INVITE 



27. 200 OK 



28. 200 OK 



29. 200 OK 



30. Resource Commit 



31. 200 OK 



32. ACK 



33. ACK 



34. ACK 



35. ACK 



36. PLAY 



37. 200 OK 



38. Content stream(s) 



CoD-MF 



NOTE 1 : The procedure and flow between the CoD-MCF and CoD-MDF is out of scope of the current release. 
NOTE 2: After successful authorization of the service initiation request, the delivery of the l<eying data (with security 

metadata) to the UE may be initiated. This would be done in accordance to the media content protection 

model for IPTV as described in TS 187 003 [10]. 

Figure A.4 



1) Initial INVITE request to Core-IMS. The INVITE offers a SDP of a media description for RTSP 
connection. 

2) Core-IMS requires for RACS to reserve resources of RTSP cormection according to the Initial INVITE. 

3) Core-IMS forwards the Initial INVITE to the CoD-SCF. 
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4) When the CoD-SCF receives the Initial INVITE request from the UE, the CoD-SCF may perform service 
authorization. The CoD-SCF selects a CoD-MF. 

5) to 6) The initial INVITE request is sent to the CoD-MF selected by the CoD-SCF. 
7) to 9) SIP 200 OK for Initial INVITE is sent from CoD-MF to the Core-IMS. 

10) Core-IMS requires for RACS to commit the reservation. 

11) SIP 200 OK response is sent back to the UE. 

12) to 15) The UE sends ACK to CoD-MF. 

16) A TCP connection for RTSP is established. 

17) Since a SIP dialog is established and a TCP connection for RTSP is estabUshed, the UE invokes RTSP 
DESCRIBE request to the CoD-MF through the established TCP connection. 

18) The CoD-MF sends a SIP 200 OK with SDP. The SDP contains the media descriptions of RTP stream to 
be used. 

19) The UE extracts the media descriptions from the SDP of the SIP 200 OK. 

20) The UE sends RTSP SETUP requests to the CoD-MF through the estabUshed TCP connection. 

21) SIP 200 OK for SETUP is sent back to the UE. 

22) The UE sends a re-INVITE request to Core-IMS. The SDP of re -INVITE contains as follows: 

■ The session description and media description for RTSP are same as that of Initial INVITE. 

■ The media descriptions for RTP content stream(s) are same as the media descriptions of 

SIP 200 OK (DESCRIBE) except for address, port number, and direction attribute. The address and 
port number are replaced by that of UE's, and "a=recvonly" direction attribute is inserted. 

23) Core- IMS requires for RACS to reserve additional resources of RTP streams according to the 
re-INVITE. 

24) to 26) re-INVITE is sent to CoD-MF. 

27) to 29) SIP 200 OK for re-INVITE is sent back to UE. 

30) Core-IMS requires for RACS to commit the reservation. 

31) SIP 200 OK for re-INVITE is sent back to the UE. 

32) to 35) The UE sends ACK to CoD-MF. 

36) RTSP PLAY request is sent to the CoD-MF. 

37) SIP 200 OK for PLAY is sent back to the UE. 

38) The CoD-MF starts sending RTP content streams to the UE. 
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A.3.1 .2 Session initiation flows for case of establislning content control 
channel and content delivery channels using RTSP method 2 



content selection 



(1) INVITE 



resource reservation 



(2) INVITE 



UE 




RACS 




Core- IMS 




CoD-SCF 




CoD-MF 



(3) Select CoDMF 



(4) INVITE 



(7) 200OK (INVITE I 



(8) 200OK (invite; 



resource commit 



(9) 200OK( INVITO 



(10)ACK 



(11)ACK 



(12)ACK 



(14) Establish TCP Connectiitin for RTSP 

(15) SETUP 



(16) 200 OK 



(17) PLAY 



(18) 200 OK 



(19) RTP 



(5) INVITE 



(6) 200OK (INVITE 



(13)ACK 



-> 



Figure A.5 

1) to 2) The UE sends the initial SIP INVITE request to the SCF. 

3) The SCF can deny service requests packages depending on operator pohcy e.g. based on UE location 
(provided by the NASS), UE capabilities or the User Proiile. The SCF selects the appropriate MF. 

4) to 5) The SCF sends initial SIP INVITE request to the selected MF. 

6) to 9) SIP 200 OK of initial SIP INVITE is sent back to the UE as for final session agreement. 
10) to 13) SIP ACK is sent back to the MF. 
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14) TCP connection for the RTSP content control channel is established between the UE and the MF. The UE 
detects that the RTSP related SDP data negotiated during the preceding steps. If the RTSP session ID 
parameter is missing in this SDP, as described in clause 5.1.4.2.1, the UE knows that no RTSP session 
exists at the MF. Therefore the UE will use RTSP SETUP to trigger RTSP session initiation. 

15) The UE sends an RTSP SETUP request to the MF. 

16) RTSP 200 OK for RTSP SETUP is sent back to the UE. The RTSP network parameters exchanged during 
steps 15 and 16 equal the RTSP network parameters as agreed in steps 1 to 13. If the MF or the UE detect 
deviating parameters they react with appropriate error messages and terminate SIP and RTSP sessions. 

17) RTSP PLAY request is sent to the MF. 

18) RTSP 200 OK for RTSP PLAY is sent back to the UE. 

19) The RTP stream is sent to the client IP address as indicated by SIP SDP and RTSP SETUP. 

A.3.1A SCF-initiated session initiation 

The procedures for SCF-initiated CoD session are based on RFC 3725 [1.16] - Best Current Practices for Third Party 
Call Control (3pcc) in the Session Initiation Protocol (SIP), Flow I., see figure A.5A. 
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UE 



RACS 



Core IMS 



DoD-SCF 



2. INVITi: no SDP 



3. 2CD0K 



J. INVITE no SDP 



4. Resource Reservation 



5. 200 OK 



6. Select CoD-MF 



7. INVITE 



8. INVITE 



9. 200 OK 



10. 200 OK 



1 1 . ACK 



13. ACK 



14. Resource Commit 



15. \CK 



12.>^CK 



CoD-MF 



Method 1 : Steps 1 6 onwards from Figure A.4 in A.3. 1 . 1 



Method 2: Steps 14 onwards from Figure A.5 in A.3.1.2 



Figure A.5A: SCF-initiated CoD session 

1) The SCF sends an initial INVITE to the Core IMS. For example when a user has preselected content 

2) The INVITE is forwarded to the UE 

3) The UE accepts the INVITE and send a SIP 200 OK to the Core IMS 

4) The Core IMS reserves resources based on the SDP offer from the UE 

5) The Core IMS forwards the SIP 200 OK to the SCF 

6) The SCF selects a CoD-MF 

7) The SCF sends an INVITE with the offer of the UE to the selected MF through the Core IMS 

8) The Core IMS forwards the INVITE to the MF 

9) The MF accepts the request and sends a SIP 200 OK with an SDP answer to the Core IMS 

10) The Core IMS forwards the SIP 200 OK to the SCF 

1 l)The SCF sends an ACK to the MF through the Core IMS 
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12) The Core IMS forwards the ACK to the MF 

13) The SCF sends an ACK with an SDP answer to the UE through the Core IMS 

14) The Core IMS commits the resource reservation 

15) The Core IMS forward the ACK to the UE 

After receiving the ACK the UE can use one of two methods to start receiving the media stream. These are the same for 
UE-initiated CoD session initiation and SCF-initiated CoD session initiation, and figure A.5 refers to these steps 
described in clause A.3.1. 



A.3.2 Session termination 



UE 



RACS 



Core-IMS 



CoD-SCF 



CoD-MF 



TCP Connection for RTSP 



Content stream(s) 



1 . TEARDOWN 



2. RTF content stream(s) is tenninated 
3. 200 OK 



4. TCP connectioh is disconnected 

5. BYE 



6. Resource Release 



13. 200 OK 



8. BYE 


5YE 


^ 

9. E 


10. 200 OK 


11 . 200 OK 




12. 200 OK 


< 



NOTE: The procedure and flow between the CoD-MCF and CoD-MDF is out of scope of the current release. 

Figure A.6 

1) TEARDOWN request is sent to CoD-MF. 

2) CoD-MF stops sending RTF content streams. 

3) The CoD-MF responds with RTSP 200 OK response. 

4) The UE disconnects the TCP connection of RTSP. 

5) The UE sends the BYE request towards Core-IMS. 

6) Core-IMS requires for RACS to release resources. 

7) to 9) BYE is sent to CoD-MF. 

10) to 13) SIP 200 OK is sent back to the UE. 
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A.3.3 Session modification 

A.3.3.1 Session modification initiated by MF 



UE 




RACS 




Core- IMS 




CoD-SCF 




CoD-MF 



content selection 



1 . INVITE 



2. Resource Reservation 



3. INVITE 



4 . select CoDMCF 
5. INVITE 



6. INVITE 



7. 200OK 



8. 200OK 



9. 200OK 



10. Resource Commit 
11.200OK 



12 . ACK 



13.ACK 



14. ACK 



15. ACK 



1 6 . Establish TCP Connection for RTSP 



17. re- INVITE 



18. re- INVITE^ 

19. re- INVITE 



20. Resource Reservation 



21 . re- INVITE^ 
22 200OK 



23. Resource Commit 



24. 200 OK 



25. 200 OK 



26. 200OK 



27. ACK 



28 . ACK 



29. ACK 



30 . ACK 



NOTE: The procedure and flow between the CoD-MCF and CoD-MDF is out of scope of the current release. 

Figure A.7 

1) Initial INVITE request to Core-IMS. The INVITE offers a SDP of a media description for RTSP 
connection. 

2) Core-IMS requires for RACS to reserve resources of RTSP connection according to the Initial INVITE. 
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3) Core-IMS forwards the Initial INVITE to the CoD-SCF. 

4) When the CoD-SCF receives the Initial INVITE request from the UE, the CoD-SCF may perform service 
authorization. The CoD-SCF selects a CoD-MF. 

5) to 6) The initial INVITE request is sent to the CoD-MF selected by the CoD-SCF. 
7) to 9) SIP 200 OK for Initial INVITE is sent from CoD-MF to the Core-IMS. 

10) Core-IMS requires for RACS to commit the reservation. 

11) SIP 200 OK response is sent back to the UE. 

12) to 15) The UE sends ACK to CoD-MF. 

16) A TCP connection for RTSP is established. 

17) The CoD-MF sends a re-lNVlTE request to Core-IMS to establish the content delivery channel. 

18) to 19) The re-INVITE request is routed back to Core-IMS via the CoD-SCF. 

20) Core-IMS requires for RACS to reserve additional resources of RTP streams according to the 
re-lNVlTE. 

21) re-INVITE is sent to the UE. 

22) The UE sends SIP 200 OK with SDP. The SDP contains the media descriptions of RTP stream to be used. 

23) Core-IMS requires for RACS to connmit the reservation. 

24) to 26) SIP 200 OK is sent to the CoD-MF. 
27) to 30) The CoD-MF returns ACK to the UE. 

A.4 Example signalling flows of BC operation 



A.4.1 UE-initiated session initiation 



This clause describes an example of signalhng flow of session initiation when the UE retrieves network parameters 
from the SSF. 



UE 



RACS 



1. INVITE 



Core-IMS 



BC-SCF 



2. Resources Reservation 



3. INVITE 



4. 200 OK 



5. Resources Commit 



6. 200 OK 



7. ACK 



8. ACK 



9. Multicast Report - Join 



Media Stream 



ECF/EFF 



Figure A.8: Session initiation of BC operation 
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1) The UE initiates BC Service. The SIP INVITE message contains BW requirements for this session and a list of 

Service packages and multicast addresses to be authorized during the session. 

2) Core IMS identifies this is as a BC service session initiation and reserves the resources with RACS. 

3) The INVITE message is forwarded to the SCF. The SCF validates the hst of requested service packages 
against the subscriber profile associated with the UE. The SCF may remove some service packages or replace 
one with a list of multicast addresses. 

4) The IPTV appUcation sends the positive result to the IMS core. 

5) Core IMS modifies the reservation and aligns it with any modification the SCF made, as described in step 2. 
Core IMS commits the reservation with RACS. 

6) Core IMS forwards the result to the UE. 

7) UE sends ACK towards SCF. 

8) Core-IMS routes the ACK message to SCF. 

9) The UE joins the multicast address indicated in the response. 

10) Content is delivered. 

NOTE: After successful authorization of the service initiation request, the derivation and delivery of further 

necessary keying material to the UE may be initiated to enable decryption of BC streams in real time (in 
accordance to the media content protection model for IPTV as described in TS 187 003 [10]). This can be 
done statically prior to the content delivery or dynamically during the content deUvery. 



A.4.1A SCF-initiated session initiation 



UE 




RACS 




Core IMS 




BC-SCF 



1. INVITE 



2. Resource Reservation 



3. INVITE 



4. 2 )0 OK 



5. Resource Commit 



8. ACK 



10. Med 



6. 200 OK 



7. ACK 



9. Multicast Join 



a Stream 



ECF/EFF 



Figure A.8A: SCF-initiated BC session 

1) The SCF sends an initial INVITE to the Core IMS. For example when a user has preselected content. 

2) The Core IMS reserves resources based on the SDP offer from the SCF. 

3) The INVITE is forwarded to the UE. 
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4) The UE accepts the INVITE and send an 200 OK to the Core IMS. 

5) The Core IMS commits the resource reservation. 

6) The Core IMS forwards the SIP 200 OK to the SCF. 
6) The SCF sends an ACK the the UE. 

8) The Core IMS forwards the ACK to the UE. 

9) The UE joins the multicast address. 

10) Content is delivered. 

A.4.2 Session termination 

This clause describes an example of signalhng flow of session termination. 



UE 



RAGS 



Core-IMS 



BC-SCF 



2. BYE 



1. Multicast Fteport - Leave 



No Media Stream 



3. Resources Release 



6. 200 OK 



4. BYE 



5. 200 OK 



ECF/EFF 



Figure A.9: Session termination of BC operation 

1) The UE sends a multicast Leave request (Membership Report Message (IGMP) or Multicast Listener 
Report Message (MLD)) to stop receiving multicast media stream. The UE populates the message as 
follows: 

Multicast Address field is set to the multicast address to be left. 
If the protocol is IGMPv3 or MLDv2: 

■ If source addresses have been set in the Join message, the same source address list is excluded from 
the listening interface; the Record Type is set to "BLOCK_OLD_SOURCES" and Source hst is set 
to the source address. 

■ If no source address has been set in the Join message, Filter Change record is set to INCLUDE with 
an empty source hst. 

2) The UE sends a BYE request to Core-IMS. 

3) Core-IMS requires for RACS to release resources. 

4) Core-IMS forwards a BYE to the BC-SCF. 

5) to 6) The BC-SCF responds with SIP 200 OK response and the SIP session is terminated. 



A.4.3 Channel switching 



This clause describes two examples of signalling flow of channel switching. 
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A.4.3.1 Join after leave 



UE 



RAGS 



3. SIP INFO (channel) 



6. 200 OK 



Core-IMS 



BC-SCF 



2. 



Multicast Fteport - Loave 



No Media Stream 
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^oin 



Media Stream 



4. SIP INFO (chanrel) 



5. 200 OK 



ECF/EFF 



Figure A.10: Changing multicast channels of BC operation (2 messages) 

1) The UE sends a multicast Leave request (Membership Report Message (IGMP) or Multicast Listener 
Report Message (MLD)) to stop receiving the multicast media stream of the old channel. 

2) The UE sends a multicast Join request (Membership Report Message (IGMP) or Multicast Listener Report 
Message (MLD)) to start receiving the multicast media stream of the new channel. 

3) to 4) If the UE remains on the selected channel for a period of time greater than a preconfigured value 

(example 10 seconds), the UE may inform the SCF of selected channel. 

5) to 6) The SCF replies with a SIP 200 OK. 

A.4.3.2 Leave and Join at the same time 

If the Transport Function is using IGMPv3 or MLDv2, the UE may choose to send a single IGMP message containing 
the Leave request and the Join request, for leaving the old channel and joining the new channel. This is depicted in 
figure A.ll. 



UE 




RACS 




Core-IMS 




BC-SCF 




ECF/EFF 
















1. Multicast Report - 


Leave&Join 








< 











Figure A.11: Changing multicast channels of BC operation (single message) 

1) The UE sends a combined multicast Leave/Join request (Membership Report Message (IGMP) or Multicast 
Listener Report Message (MLD)) to stop receiving the multicast media stream of the old channel and start 
receiving the multicast media stream of the new channel. 
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A.5 Example signalling flows for inter-destination media 
synchronization 

A.5.1 Inter-destination media synchronization flows for SIP 
signalling 

A.5.1. General 

The functional entity "MSAS" in this clause refers to the session-level MSAS, see also clause 4.2.8. 

A.5. 1 . 1 Inter-destination media synchronization of a BC service 

This clause describes an example SIP signalling flow to initiate up a using synchronization session initiation from 
clause 5.7.1.1. 



SC MSAS 




1. INVITE 




► 

2. 200 OK 


< 

3. ACK 


>■ 



Figure A.12: SIP signalling for the session set-up of inter-destination media 
synchronization of a BC service 

NOTE: To simplify signalling flows, details on the inclusion of the IMS Core, resource reservations, on specific 
content control and delivery flows, etc. have been omitted. Only those parts of the SIP signalling flow are 
shown that are relevant for inter-destination media synchronization. See clauses 5.1.3. and 5.3.1. for 

further details on BC operation. 

1) The SC sends the initial SIP INVITE request to the MSAS. This SIP INVITE requests contains the 
synchronization group identifier (SyncGroupId). See clause 5.7.1.1 for details on the use of SyncGroupId. 

2) The MSAS responds with a SIP 200 OK, which contains the SyncGroupId and adds the MSAS parameters 
(SSRC-ID, address and port number and RTCP SyncGroupID) in the SDP description. Since the MSAS 

modifies the SC offer, it acts as a B2BUA. 

3) SIP ACK is sent back to the MSAS. 

A.5.1 .2 Inter-destination media synclironization of a CoD service using 
RTSP metliod 1 

This clause describes an example SIP signalling flow to initiate a synchronization session from clauses 5.4.10.1, 5.7.1.1 
and 5.8.1.1 using RTSP method 1. 
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SC MSAS MF 




1. INVITE 
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< 

6. ACK 
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Figure A.13: SIP signalling for the session set-up of inter-destination media synchronization of a 

COD service using RTSP method 1 



NOTE: To simplify signalling flows, details on the inclusion of the IMS Core, resource reservations, on specific 
content control and delivery flows, etc. have been omitted. Only those parts of the SIP signalling flow are 
shown that are relevant for inter-destination media synchronization. See clauses 5.1.4, 5.3.2. and 5.4.1. 
for further details on CoD RTSP method 1 operation. 

1) The SC sends the initial SIP INVITE request to the MSAS. This SIP INVITE requests contains the 
synchronization group identifier (SyncGroupId). See clause 5.7.1.1. for details on the use of SyncGroupId. 

2) The MSAS forwards the SIP INVITE to the MF, adding the MSAS parameters details (address and port 
number and RTCP SynGroupID) in the SDP description. Since the MSAS modifies the SC offer, it acts as a 
B2BUA. 

3) The MF assigns SSRC to the media RTP stream and sends a SIP 200 OK to the MSAS, adding the SSRC to 
the SDP description of the media. 

4) The MSAS forwards the SIP 200 OK to the SC, containing the SyncGroupId, the MSAS address and the 
SSRC. 



5) to 6) SIP ACKs are sent. 



A.5.1 .3 Inter-destination media synclironization of a CoD service using 
RTSP metliod 2 

This clause describes an example combined SIP and RTSP signalling flow to initiate a using synchronization session 
initiation from clauses 5.4.10.1, 5.7.1.1 and 5.8.1.1, 7.2.4. and 7.3.1, using RTSP method 2. 
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SC MSAS MF 




1. INVITE 


2. INVITE 




► 

4. zUU UK 


>■ 

3. 200 OK 


6. ACK 


■< 

5. ACK 


► 

7. DESCRIBE 


► 

► 


8. 200 OK 
< 









Figure A.14: Combined SIP and RTSP signalling for the session set-up of inter-destination media 
synclironization of a COD service using RTSP metliod 2 

NOTE 1: To simplify signalling flows, details on the inclusion of the IMS Core, resource reservations, on specific 
content control and delivery flows, etc. have been omitted. Only those parts of the combined SIP and 
RTSP flow are shown that are relevant for inter-destination media synchronization. See clauses 5.1.4, 
5.3.2, 5.4.1, 7.1.2. and 7.2.2. for further details on CoD RTSP method 2 operation. 

1) The SC sends the initial SIP INVITE request to the MSAS. This SIP INVITE requests contains the 
synchronization group identifier (SyncGroupId). see clause 5.7.1.1. for details on the use of SyncGroupId. 

2) The MSAS forwards the SIP INVITE to the MF, adding the MSAS parameters details (address and port 
number and RTCP SynGroupID) in the SDP description. Since the MSAS modifies the SC offer, it acts as a 
B2BUA. 

3) This step flows step 3 of clause A.5.1.2. 

NOTE 2: The MF is allowed to wait assigning an SSRC and to send a SIP 200 OK to the MSAS without adding the 
SSRC to the SDP description of the media. 

4) This step flows step 4 of clause A.5.1.2. 

NOTE 3: It is allowed that the MSAS forwards the SIP 200 OK to the SC, containing only the SyncGroupId and 
the MSAS address. 

5) to 6) SIP ACKs are sent. 

7) The SC invokes RTSP DESCRIBE request to the MF.s 

8) If the MF has not conveyed the SSRC towards the MSAS in step 3, the MF assigns an SSRC and sends 200 
OK with SDP. The SDP contains the SSRC as an attribute in the SDP description. 

A.5.2 Inter-destination media synchronization flows for RTCP 
signalling 

A.5.2.0 General 

The functional entity "MSAS" in this clause refers to the media-level MSAS, see also clause 4.2.8. 
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A.5.2.1 Inter-destination media synchronization of BC service 

This clause describes an example RTCP signalling flow for the exchange of using synchronization status and settings 
instructions exchange from clause 11.3 and 11.4. 



sc 




MSAS 




l.RTCPRR + XR(status) 






2. RTCP XR(settings) 


< 



Figure A.15: RTCP signalling for the excliange of synchronization status and 
settings instructions for a BC service 



NOTE 1: To simplify signalhng flows, details on the inclusion of the IMS Core, resource reservations, on specific 
content control and delivery flows, etc. have been omitted. Only those parts of the flow are shown that are 
relevant for inter-destination media synchronization. 

1) The SC sends RTCP Receiver Report (RR) to the MSAS. This report includes t includes an extended 
Report (XR) containing the synchronization status information according to annex W. 

2) The MSAS sends an RTCP XR containing synchronization settings instructions directly to the SC, according 
to annex W. 

NOTE 2: The MSAS may forward RTCP RR to the source of the media, see also clause 1 1 on the use of RTCP. 
RTCP SR are sent directly from media source to SC. 

A.5.2.2 inter-destination media synclnronization of CoD service 

This clause describes an example RTCP signalhng flow for the exchange of using synchronization status and settings 
exchange from clause 1 1.3 and 1 1.4. 
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MF 



2. RTCP RR 



3. RTCP SR 



Figure A.16: RTCP signalling for the exchange of synchronization status and 
settings instructions for a CoD service 
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NOTE: To simplify signalling flows, details on the inclusion of the IMS Core, resource reservations, on specific 
content control and delivery flows, etc. have been omitted. Only those parts of the flow are shown that are 
relevant for inter-destination media synchronization. 

1) The SC sends RTCP Receiver Report (RR) to the MSAS. This report includes includes an eXtended Report 
(XR) containing the synchronization status information, according to annex W. 

2) The MSAS removes the XR from the RR and forwards the RR to the source of the media. 

3) The MF sends its RTCP Sender Reports (SR) to the MSAS. 

4) The MSAS adds the XR containing the settings instructions to the SR according to annex W, and forwards this 
to the SC. 



A.5.2.3 RTCP exchange between UEs directly 

This clause describes an example RTCP flow for inter-destination media synchronization between two UEs directly. 
Both UEl and UE2 have SC functionality. UEl acts also as MSAS, see figure A. 17. If the RTP/RTCP flows ai-e 
handled by a server (e.g. a conference bridge), then the MSAS functionality may also be located there. 




Sync 




Figure A.17: UE acting as IVISAS for inter-destination media synclironization 

between UEs 



Figure A. 18 shows an example RTCP flow for inter-destination media synchronization between two UEs directly. 
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XR (settings) 



Figure A.18: RTCP signalling for the exchange of synchronization status and 
settings instructions between UEs directly 
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1) UEl and UE2 have a media session, which includes regular RTP/RTCP exchange for the media transport and 
transport control. 

2 to 3) UEl and UE2 each have a BC or CoD session for the same service and content. 

4 to 5) UEl and UE2 reuse their regular RTCP SRs and RRs to append RTCP Extended Reports (XR) [45] for the 
exchange of Synchronization information. See also clauses 11.3 and 11.4. 

UEl and UE2 have to obtain the SyncGroupID, the SSRC value and the MSAS address (=UE1 address) before step 4. 
These may be obtained using the procedures as described in clauses 5.4.10, 5.7.1.1, 5.8.1.1 and 7.3. 

A.5.2.4 RTCP exchange for sync' 

This clause describes an example RTCP flow for sync', see figure A.16. 



SC MSAS 




1. RTCP XR 
(correlation) ^ 







Figure A.19: RTCP flow for sync' 

1) SC sends MSAS synchronization correlation information: RTCP extended Reports (XR) related to the 

incoming media stream and RTCP eXtended Reports (XR) (annex W) related to the outgoing media stream, 
see annex W. 

Synchronization correlation information may be sent from SC to MSAS at regular pre-configured time intervals. 
Figure A. 17 are example RTCP XR messages for sync', see also annex W. 
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12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I V=2 I P| reserved | PT=XR=2 07 | length=9 | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I SSRC of packet sender SC | 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
I BT=9 |SPST=3 |0| block length=7 | 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 
I PT I Reserved | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Media Stream Correlation Identifier, same for in and out | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I SSRC of incoming media stream | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Packet Received NTP timestamp, most significant word | 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 
I Packet Received NTP timestamp, least significant word | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Packet Received RTP timestamp | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Packet Presented NTP timestamp = empty | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
I V=2 I P| reserved | PT=XR=207 | length=9 | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I SSRC of packet sender SC | 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
I BT=9 |SPST=4 |0| block length=7 | 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 
I PT I Reserved | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Media Stream Correlation Identifier, same for in and out | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I SSRC of outgoing media stream | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Packet Received NTP timestamp, most significant word | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Packet Received NTP timestamp, least significant word | 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 
I Packet Received RTP timestamp | 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 
I Packet Presented NTP timestamp = empty | 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 



Figure A.20: Example RTCP messages for sync' 



A.6 Example signalling flows of content insertion 
A.6.1 Content insertion at the UE 

This flow shows an example of content insertion that is triggered by an event detected at the SCF, e.g. for targeted ad 
insertion. 
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MF 



(0) Ongoing BC with trickplay or CoD session 




(4) New session for content insertion 



Figure A.21 

0) An ongoing session exists between UE and MF for BC with trick play or CoD. 

1) The SCF detects an event that triggers the content insertion and selects the appropriate content to be 
inserted. The SCF can determine the duration of the content insertion depending on e.g. the (expected) 
length of the time interval that is available for content insertion, the user identity, the semantic context of 
the content in the ongoing session, the geographic location of the UE and its local time. 

2) The SCF sends a notiiication to the UE concerning content insertion with SIP INFO, according to 
clause 5.3.12.1. 

3) The UE sends initiates a new session for the inserted content with SIP INVITE. The INVITE contains 
Service Action Data, according to clause 5.1.13. 

4) A new session starts for content insertion. 



A. 6. 2 Content insertion at the UE during pause 

This flow shows an example of content insertion that is triggered at a user request, when a user pauses CoD content. 
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Figure A.22 

0) An ongoing session exists between UE and MF for BC with trick play or CoD. 

1) The UE sends an RTSP PAUSE to the MF. 

2) The UE informs the SCF of the paused content with SIP INFO. 

3) The SCF selects the appropriate content to be inserted. The SCF can determine the duration of the content 
insertion depending on e.g. the (expected) length of the time interval that is available for content 
insertion, the user identity, the semantic context of the content in the ongoing session, the geographic 
location of the UE and its local time. In the case of content insertion during a pause. The (expected) 
length of the time interval is indicated by the UE in the INFO message. 

4) The SCF sends a notification to the UE concerning content insertion with SIP INFO, according to 
clause 5.3.12.1. 

5) The UE sends initiates a new session for the inserted content with SIP INVITE. The INVITE contains 
Service Action Data, according to clause 5.1.13. 

6) A new session starts for content insertion. 



A.7 Example signalling flows for session transfer 

The call flow shows an example of session transfer push mode where the session is pushed from the transferor to the 
transferee. Note that in the call flow it is assumed that the SCC application server is embedded in the SCF. This is for 
convenience and can indeed be a stand alone accplication server with no change to the general procedure. 

The following is a brief description of the steps in the call flow: 

a) Initially the transferor has established a CoD session as per clause 5.4. 1 . 

b) To select the device to which the transferor can push the session, the transferor subscribes to the registration 
event package to receive a Ust of registered devices. This is accomplished in steps 1 and 2 in the call flow. 
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c) The UE receives the list of registered in devices in the SIP NOTIFY in step 3, and responds to it in step 4 with 
a SIP 200 OK. 

d) The transferor selects the device, and then sends a SIP REFER targeted to that device. This is accomplished in 
steps 5 and 6. 

e) The transferee receives the SIP REFER, extracts the pertinent information and responds with a SIP 200 OK 
Accepted to the transferee in steps 7 and 8. 

f) The transferor now attempts to establish the new CoD session as per the procedure defined in clause 5 .4. 1 . 

g) Following the successful establishment of the session, the SCC AS clears the old session; This is accomplished 
through steps 10 and 11. 

h) The transferee than notifies the transferor of the successful transfer of the session through steps 12 to 15. 

i) The transferee then starts playing the content from the received bookmark and the transfer procedure has now 
been successfully completed. 
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Annex B (normative): 

IPTV services XCAP application usage 

B.1 General 

For the purpose of manipulating data stored in an application server the XML Configuration Access Protocol 
(XCAP) defined in RFC 4825 [9] is used. XCAP allows a cUent to read, write and modify application configuration 
data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, 
so that these components can be directly accessed by HTTP. XCAP uses the HTTP methods PUT, GET and DELETE 
to operating on XML documents stored in the server. 

In the case of IPTV services, the data stored in a server is related to the execution of that given service. The present 
document defines a new XCAP Application Usage for the purpose of allowing a client to manipulate data related to 
IPTV services. This application usage defines the XML schema for the data used by the appUcation, along with other 

key pieces of information. 

XCAP defines two logical roles: XCAP chent and XCAP servers. An XCAP client is an HTTP/1.1 compliant client. 
Similarly an XCAP server is an HTTP/1.1 compUant server. The XCAP server acts as a repository of XML docimients 
that customize and modify the execution of IPTV services. 

XCAP focuses on the definition of XML documents that are compliant with the XML schema and constrains defined 
for a particular XCAP application usage. XCAP allows appUcation to provide XML documents that are common for all 
users or XML documents that affect the service of a given user. 

Central to XCAP is the construction of the HTTP URl that points to particular XML document or certain components of 
it. A component in an XML document can be an XML element, attribute, or the value of it. 



B.2 XCAP application usage 

XCAP requires application usages to fulfil a number of steps in the definition of such application usage. The reminder 
of this clause specifies the required definitions of the IPTV services XCAP Application Usage. 

Application Unique ID (AUID): Each XCAP application usage is associated with a unique name called the 
AppUcation Unique ID (AUID). The AUID defined by this appUcation usage falls into the vendor-proprietary 
namespace of XCAP AUID, where ETSI is considered a vendor. 

The AUID allocated to the NGN IPTV services XCAP application usage is: 

org . etsi . ngn . iptv 

XML schema: Implementations in compUance with the present document shall implement the XML schema defined in 
annex C 

default namespace: XCAP requires application usages to declare the default namespace. The default namespace of the 
IPTV services XCAP appUcation usage is: 

urn : org : etsi : ngn : params : xitil : ns : iptv 

MIME type: The MIME type of IPTV services XML documents is: 

application/vnd.etsi . iptvprof ile+xml 

validation constraints: The present document does not specify any additional constraint beyond those defined by 
XCAP. 
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data semantics: The XML schema does not accept URIs that could be expressed as a relative URI reference causing a 
resolution problem. However, each of the supplementary services should consider if relative URIs are allowed in the 
subdocument tree, and in that case, they should indicate how to resolve relative URI references. In the absence of 
further indications, relative URI references should be resolved using the document URI as the base of the relative URI 
reference. 

naming conventions: By default, NGN IPTV services XML documents are stored under the user's Home Directory 
(which is located under the "users" sub-tree). In order to facilitate the manipulation of an NGN IPTV services XML 
document, we define a default XML file name: 

iptvprof ile .xmi 

resource interdependencies: The present document does not specify additional resource interdependency beyond those 
specified in the XML schema. 

authorization policies: The default XCAP authorization policy is used in the appUcation usage defined by the present 
document. 

NOTE: The default pohcy indicates that the creator of the XML document is the one that is authorized to 
manipulate it. 
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Annex C (normative): 

XML Schema for the IPTV profile 

This annex specifies an XML schema for creating documents representing instances of the TFTY profile described in 
TS 182 027 [2]. This XML schema is used when IF*TV profile is manipulated with the XCAP procedure described in 
clauses 6.1.2.1, 6.2.1.2, and annex B. 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 

<xs : schema 

xmlns : xs = "http : //www . w3 . org/2 Ol/XMLSchema" 
xmlns : uep= "urn : org : etsi : ngn : params ;xml :ns : iptvueprof ile" 
element FormDefault= "qualified" 
attributeFormDef ault= "unqualified" > 

<xs : import namespace= "urn : org : etsi : ngn : params : xml : ns : iptvueprof ile" 
schemaLocation= "Annex P_XML Schema for UE Prof ile .xsd" /> 

<xs : element name= " IPTVProf ile " > 
<xs : annotation> 

<xs : documentation> XML Schema for representing the IPTV Profile object 
182 027 clause 7.3.1 

</xs :documentation> 
</xs :annotation> 
<xs : complexType> 

<xs : sequence> 

<xs:element name= "UEProf ile " type="uep : tUEProf ile" minOccurs= " " /> 
<xs:element name="GlobalSettings" type= " tGlobalSettings " minOccurs 
<xs:element name="BCProf ile" type= " tBCProf ile " minOccurs= " " /> 
<xs: element name= " CoDProf ile " type= " tCoDProf ile " minOccurs= " " / > 
<xs:element name="PVRProf ile" type= " tPVRProf ile " minOccurs= " " /> 
<xs:element name="PChProf ile" type="tPChProf ile" minOccurs="0"/> 
<xs:element name="UGCProf ile" type="tUGCProf ile" minOccurs="0"/> 
<xs:element name="Extension" type="tExtension" minOccurs="0"/> 
<xs:any namespace="##other" processContents= " lax" minOccurs= " " 
maxOccurs= "unbounded" /> 

</xs : sequence> 

<xs : attribute name="Prof ileld" type="xs:ID" /> 
<xs :anyAttribute/> 
</xs : complexType> 
</xs :element> 



<xs : complexType name= "tBCProf ile" > 
<xs : sequence> 

<xs:element name="BCServicePackage" type="tBCServicePackage" 
minOccurs= " 1 " maxOccurs= "unbounded" /> 

<xs: element name= " IPTVContentMarkerAuthorizedViewUser " type= "xs : string" minOccurs= " " 
maxOccurs= "unbounded" /> 

<xs: element name= " IPTVContentMarkerSourceUser " type= "xs : string" minOccurs= " " 
maxOccurs= "unbounded" /> 

<xs:element name= "Extension" type="tExtension" minOccurs= " " /> 

<xs;any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tBCServicePackage" > 
<xs : sequence> 

<xs;element name= "BCPackageld" type="tBCServicePackageID" minOccurs="l"/> 
<xs:element name= "Description" type="tBCServicePackageDescription" minOccurs="0"/> 
<xs:element name="BCService" type="tBCService" minOccurs= " " maxOccurs= "unbounded" /> 
<xs;element name= "Extension" type="tExtension" minOccurs= " " /> 

<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name="tBCServicePackageID" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs :minLength value="0"/> 
<xs :maxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 
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<xs : simpleType name="tBCServicePackageDescription" final="list restriction"> 
<xs : restriction base="xs : string" > 
<xs :minLength value="0"/> 
<xs imaxLength value="64"/> 
</xs : restriction> 
</xs : simpleType> 



<xs : complexType name= " tBCService" > 
<xs : sequence> 

<xs:element name= "BCServiceld" type="tBCServiceID" minOccurs= " 1 " /> 
<xs:element name= "QualityDef inition" type="tQualityDef inition" minOccurs="0"/> 
<xs:element name= "Extension" type="tExtension" minOccurs= " " /> 

<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 



<xs : simpleType name="tBCServiceID" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs :minLength value="0"/> 
<xs :maxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 



<xs : simpleType name="tQualityDef inition" final="list restriction" > 
<xs : restriction base="xs :unsignedByte"> 
<xs :minlnclusive value="0"/> 
<xs :maxlnclusive value="l"/> 
<xs : enumeration value="0"> 
<xs :annotation> 

<xs : documentation> 

< label xml : lang= "en" >SD</ label > 

<def inition xml : lang= "en" >Standard Def inition</def inition> 
</xs : documentation> 
</xs :annotation> 
</xs : enumeration> 
<xs : enumeration value="l"> 
<xs :annotation> 

<xs : documentation> 

< label xml : lang= "en" >HD</ label > 

<def inition xml : lang= "en" >High Def inition</def inition> 
</xs :documentation> 
</xs :annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType> 



<xs : complexType name= " tCoDProf ile" > 

<xs : sequence> 

<xs:element name= " ParentalControl " type= " tParentalControlLevel " minOccurs= " " /> 

<xs: element name= " IPTVContentMarkerAuthorizedViewUser " type= "xs : string" minOccurs= " " 
maxOccurs= "unbounded" /> 

<xs: element name="IPTVContentMarkerSourceUser" type= "xs : string" minOccurs= " " 
maxOccurs= "unbounded" /> 

<xs: element name= "Extension" type= " tExtension" minOccurs= " " / > 

<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 



<xs : simpleType name= " tParentalControlLevel " final="list restriction" > 
<xs : restriction base= "xs : unsignedByte" > 
<xs : minlnclusive value="0"/> 
<xs : maxinclusive value="5"/> 
<xs : enumeration value="0"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >ALL</label> 

<def inition xml : lang= " en" >A11 contents</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="l"> 
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<xs ;annotation> 

<xs : documentation> 
<label xml : lang= 
<definition xml: 
</xs ; documentation> 
</xs :aimotation> 
</xs : enumeration> 
<xs : enumeration value="2"> 
<xs :annotation> 

<xs : documentation> 
<label xml : lang= 
<definition xml: 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="3"> 
<xs : annotation> 

<xs : documentation> 
<label xml : lang= 
<definition xml: 
</xs : documentation> 
</xs :annotation> 
</xs : enumeration> 
<xs : enumeration value="4"> 
<xs :annotation> 

<xs : documentation> 
<label xml : lang= 
<definition xml: 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="5"> 
<xs :annotation> 

<xs : documentation> 
<label xml : lang= 
<definition xml: 
</xs :documentation> 
</xs :annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType> 



"en">Level l</label> 

lang= "en" >Level 1 contents</def inition> 



"en">Level 2</label> 

lang="en">Up to level 2</def inition> 



"en">Level 3</label> 

lang="en">Up to level 3</def inition> 



"en">Level 4</label> 

lang="en">Up to level 4</def inition> 



"en">Level 5</label> 

lang="en">Up to level 5</def inition> 



<xs : complexType name= " tPVRProf ile" > 
<xs : sequence> 

<xs :annotation> 

<xs ; documentation> 

Unit of the StorageLimitlnVolume element is the GigaOctet 
</xs :documentation> 
</xs :annotation> 

<xs: element name="PVRPref erence" type="tPVRPref erence"/> 

<xs:element name="StorageLimitInTime" type="tNPVRStorageLimitInTime" minOccurs="0"/> 
<xs: element name= " StorageLimitlnVolume " type= " tNPVRStorageLimitlnVolume " minOccurs= " " /> 
<xs: element name= "AuthorizedControlUser " type= " tAuthorizedControlUser " minOccurs= " " / > 
<xs: element name= " IPTVContentMarkerAuthorizedViewUser " type= "xs : string" minOccurs= " " 

maxOccurs="unbounded" /> 

<xs: element name= " IPTVContentMarkerSourceUser " type= "xs : string" minOccurs= " " 

maxOccurs= "unbounded" /> 

<xs:element name="Extension" type= " tExtension" minOccurs= " " /> 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType > 

<xs : simpleType name= " tPVRPref erence" final="list restriction" > 
<xs : restriction base= "xs : unsignedByte" > 
<xs : minlnclusive value="0"/> 
<xs : maxinclusive value="l"/> 
<xs : enumeration value="0"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Network</label> 

<definition xml : lang= " en" >Recording is done in the network</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="l"> 
<xs : annotation> 

<xs : documentation> 
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<label xml : lang= "en" >User_Equipment</label> 
<definition xml ; lang="en">Recording is done on the user 

equipment</def inition> 

</xs : documentation> 
</xs :annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name= " tNPVRStorageLimitlnTime" > 
<xs : restriction base="xs : duration" > 
<xs :minlnclusive value="PTOH"/ > 
<xs :maxlnclusive value="PT1000000000H"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name= " tNPVRStorageLimitlnVolume" > 

<xs : restriction base= "xs :nonNegativeInteger " / > 
</xs : simpleType> 

<xs : simpleType name="tAuthorizedControlUser" final="list restriction" > 

<xs : restriction base="xs : string"/ > 
</xs : simpleType> 

<xs : complexType name="tGlobalSettings"> 
<xs : sequence> 

<xs:element name="LanguagePreference" type="tLanguage" minOccurs="0"/> 
<xs :element name="UsersActionRecordable" type="tUserActionRecordable"/ > 
<xs:element name= "Extension" type="tExtension" minOccurs= " " /> 

<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType> 



<xs : simpleType name="t Language "> 

<xs : restriction base="xs : string" > 
<xs :annotation> 

<xs : documentation> 

<definition xml : lang="en">ISO 639-2 Language code</def inition> 
</xs : documentation> 
</xs :annotation> 
<xs :minLength value="3"/> 
<xs :maxLength value="3"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name= " tExtension" > 
<xs : sequence> 

<xs:any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 



<xs : simpleType name="tUserActionRecordable"> 

<xs : restriction base="xs : boolean" /> 
</xs : simpleType> 



<xs : complexType name= " tPChProf ile" > 
<xs : sequence> 

<xs: element name= " PChList " minOccurs= " 1 " maxOccurs= "unbounded" > 

<xs : complexType > 
<xs : sequence > 

<xs: element name= " PChltem" minOccurs= " 1 " maxOccurs= "unbounded" > 
<xs : complexType > 
<xs : sequence> 

<xs:element name= " PChltemServiceType" type= "xs : string" /> 
<xs: element name= " PChltemContentId" type= "xs : anyURI " /> 
<xs:element name= " PChltemStartTime " type= "xs : dateTime" /> 
<xs: element name="PChItemEndTime" type="xs idateTime" /> 
<xs: element name="PChItemOf f set" type= "xs : duration" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 

<xs : attribute name="PChId" type= "xs : anyURI " use= "required" /> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : complexType> 
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<xs : complexType name= " tUGCProf ile" > 
<xs : sequence> 

<xs:element name="UGCProf ile" minOccurs= " " maxOccurs= "unbounded" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name= "UGCStorageLimit " type="xs :unsignedInt"/> 
<xs: element name= "AuthorizedControlUser " type= "xs : string" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : complexType> 

</xs : schema> 

NOTE 1: The list of parameter that could be sent to the UE over UT is specified in the procedures clause. 

NOTE 2: The UE profile used for service discovery may be considered in the same XML schema, indicating 
exphcitly which part to used for the different purposes. 
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Annex D (normative): 

XML Schema for IPTV commands 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<xs : schema 

targe tNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvactiondatacommand" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvactiondatacommand" 
xmlns : be = "urn : org : etsi : ngn : params : xml : ns : iptvbcserviceactiondata" 
xmlns : CO = "urn : org : etsi : ngn : params : xml : ns : iptvcodserviceactiondata" 
xmlns : np = "urn : org : etsi : ngn : params : xml : ns : iptvnpvrserviceactiondata" 

xmlns :Cp = "urn : org : etsi :ngn:params :xml :ns : iptvcpvrserviceactiondata" 

xmlns :Ci ="urn : org : etsi : ngn ; params :xml :ns : iptvcontent insert ionserviceactiondata" 

xmlns : xs= "http : //www . w3 . org/2 01/XMLSchema" element FormDefault= "qualified" 

attributeFormDef ault= " unqualified" > 

<xs : import namespace= "urn : org : etsi : ngn: params :xml :ns : iptvbcserviceactiondata" 
schemaLocation= "Annex K_XML Schema for BC service related data.xsd"/> 

<xs : import name space = "urn : org : etsi : ngn : params : xml : ns : iptvcodserviceactiondata" 
schemaLocation= "Annex K_XML Schema for CoD service related data.xsd"/> 

<xs : import namespace= "urn : org : etsi : ngn : params :xml :ns : iptvnpvrserviceactiondata" 
schemaLocation= "Annex K_XML Schema for N-PVR service related data.xsd"/> 

<xs : import namespace= "urn : org : etsi : ngn : params : xml : ns : iptvcpvrserviceactiondata" 
schemaLocation= "Annex K_XML Schema for CPVR service related data.xsd"/> 

<xs : import namespace= "urn : org : etsi : ngn : params :xml :ns : iptvcontent insert ionserviceactiondata" 
schemaLocation= "Annex K_XML Schema for Content Insertion service related data.xsd"/> 

<xs : element name= " IPTVActionDataCommand" > 
<xs : complexType> 
<xs : choice> 

<xs: element name= "Notify" type= " tNotif y" minOccurs= " " maxOccurs= "unbounded" / > 
<xs: element name= "Record" type="tRecord" minOccurs= " " maxOccurs= "unbounded" /> 
<xs:element name="SwitchToTM" type="tSwitchToTM" minOccurs= " " 
maxOccurs= "unbounded" /> 

<xs:element name="SwitchToBC" type="tSwitchToBC" minOccurs= " " 
maxOccurs= "unbounded" / > 
</xs : choice> 
</xs : complexType> 
</xs ;element> 

<xs : complexType name="tNotify"> 
<xs : choice> 

<xs:element ref = "be : IPTVBcActionData" /> 
<xs:element ref ="co: IPTVCodActionData" /> 
<xs:element ref = "np : IPTVNpvrActionData" /> 
<xs: element ref ="cp : IPTVCpvrActionData" /> 
<xs : element ref = " ci : IPTVContentlnsertionActionData" /> 
</xs : choice> 
</xs : complexType> 

<xs : complexType name= " tRecord" > 
<xs : choice> 

<xs: element ref ="bc : IPTVBcActionData" /> 
<xs: element ref ="np : IPTVNpvrActionData" /> 
<xs: element ref ="cp : IPTVCpvrActionData" /> 
</xs : choice> 
</xs : complexType > 

<xs : complexType name="tSwitchToTM" > 

<xs : choice> 

<xs:element ref = "be : IPTVBcActionData" /> 

</xs : choice> 
</xs : complexType> 

<xs : complexType name="tSwitchToBC" > 

<xs : choice> 

<xs:element ref = "be : IPTVBcActionData" /> 

</xs : choice> 
</xs : complexType> 
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</xs : schema> 

NOTE: Table D.l recaps the presence of each element in the Service Action Data for the different commands. 



Table D.1 





Notify 
UE - > CN 


Notify 
UE < - CN 


Record 
UE - > CN 


SwitchToTM 
UE - > CN 


SwitchToBC 
UE - > CN 


IPTVBcActionData 




BCServiceld 





M 


M 


M 


M 


Programmeld 











X 


X 


Bookmark 








M 


X 


X 


BookmarkExpiryTime 











X 


X 


IPTVCodActionData 




CoDId 


M 


M 


NA 


NA 


NA 


CoDDeliveryStatus 


M(parked) 


M 


CoDOffset 


M 


M 


CoDOffsetExpiryTime 


X 







IPTVNpvrActionData 




NPVRContentId 


NA 


M 





NA 


NA 


BCServiceld 


M 


M 


RecordStartDate 


M 





RecordEndDate 


M 





RecordStatus 


M 


X 


RecordOffset 


M 





RecordOff set Expi ryTi me 





X 


RecordExpiryTime 





X 


1 PTVCpvr Act 1 n Data 




CPVRContentId 


NA 


M 





NA 


NA 


BCServiceld 


M 


M 


TargetUEId 


M 


M 


RecordStartDate 


M 





RecordEndDate 


M 





RecordStatus 


M 


X 


IPTVContentlnsertionActionData 




IPTVContentldentifier 


M 


M 


NA 


NA ^ 




InsertedContentldentifier 


M 


M 


Insertionlime 








InsertionStatus 


M 


M 


NOTE: M = Mandatory. 
= Optional. 
X = Not included. 
NA= Not Applicable. 
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Annex E (normative): 

XML schema for IPTV presence document extension 

This XML schema is be used when the presence documents are published by the UE as described in clause 5.1.6. 

<xs : schema t argetName space = "urn : org : etsi : ngn : params :xml : ns : iptvpresence" 

xmlns : ns= "urn : org : etsi : ngn : params : xml : ns : iptvpresence" 

xmlns : oma= "urn : oma : xml : prs : pidf : oma-pres " 

xmlns : ss= "urn : org : etsi : ngn : params : xml : ns : iptv" 

xmlns :xs="http : //www.w3 . org/2 1/XMLSchema" 

element FormDefault= " qualified" 

attributeFormDef ault= "unqualified" > 

<xs : complexType name= " tBCServicePresence" > 
<xs : sequence> 

<xs:element name= " CurrentBCServicelD " type= "ns : tBCServicelD" minOccurs= " " /> 
<xs:element name="CurrentBCProgramID" type= "ns : tCurrentBCProgramID" minOccurs= " " /> 
<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs ; complexType name= " tCoDServicePresence " > 
<xs : sequence> 

<xs:element name="CurrentCODContentID" type= "ns : tCurrentContentID" minOccurs="0"/> 
<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tNPVRServicePresence" > 
<xs : sequence> 

<xs:element name= " CurrentNPVRContentID" type= "ns : tCurrentContentID" minOccurs="0"/> 
<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name="tCurrentBCProgramID" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs :minLength value="0"/> 
<xs :maxLength value="256"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="tCurrentContentID" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs :minLength value="0"/> 
<xs :maxLength value="256"/> 
</xs : restriction> 
</xs : simpleType> 

<xs ; simpleType name="tBCServiceID" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs :minLength value="0"/> 
<xs imaxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="tServiceAccessHistory"> 
<xs : sequence > 

<xs:element name="ServiceType" type="ns : tServiceType" minOccurs= " " /> 

<xs:element name="Ref erencedContentID" type="ns : tRef erencedContentID" minOccurs=" " /> 
<xs:element name="Rating" type="ns : tRating" minOccurs=" " /> 
<xs:element name="AccessStartTime" type="xs : dateTime" minOccurs=" " /> 
<xs:element name="AccessEndTime" type="xs : dateTime" minOccurs=" " /> 
<xs:element name="HistoryExpireTime" type="ns : tHistoryExpireTime" minOccurs=" " /> 
<xs:any namespace="##other" processContents="lax" minOccurs=" " maxOccurs="unbounded"/> 
</xs : sequence > 
</xs : complexType> 

<xs : simpleType name=" tServiceType" final="list restriction" > 
<xs : restriction base="xs : string" > 
<xs : enumeration value="BC"/> 
<xs : enumeration value="CoD"/> 
<xs : enumeration value="PW"/> 
<xs : enumeration value="Time Shift"/> 
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<xs : enumeration 
<xs : enumeration 
<xs : enumeration 
</xs : restriction> 
</xs : simpleType> 



value="UGC'7> 
value="SSC'7> 
value="PSC'7> 



<xs : simpleType name="tReferencedContentID" final="list restriction" > 
<xs :annotation> 

<xs : documentation xml : lang="en"> 

Identifier of the associated content accessed by the user in the context of specific 

ServiceType . 

</xs ; documentation> 
< /xs : annotation> 

<xs : restriction base="xs : string" > 

<xs :minLength value="0"/> 
<xs :maxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 



<xs : simpleType name="tRating" final="list restriction" > 
<xs : restriction base="xs :unsignedByte" > 
<xs :minlnclusive value="0"/> 
<xs :maxlnclusive value="5"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="tHistoryExpireTime" final="list restriction" > 
<xs : restriction base="xs : duration" > 
<xs :minlnclusive value="PTOH"/> 
<xs :maxlnclusive value="PT10000H"/> 
</xs : restriction> 
</xs : simpleType> 



<xs : complexType name="tServiceStateDataPresence"> 
<xs : sequence > 

<xs:element name="IPTVServiceState" type="ns : tIPTVServiceState" maxOccurs="unbounded"/> 

</xs : sequence> 
</xs : complexType> 

<xs : complexType name= "tIPTVServiceState" > 
<xs : annotation> 

<xs : documentation xml : lang="en" > 
Depending on the value of the ServiceType some elements may or may not be applicable. 
This XML Schema is recursive for ServiceTypes "SSC" and "PSC". 
</xs : documentation> 
</xs : annotation> 
<xs : sequence> 

<xs:element name=" ServiceType" type="ns : tServiceType" minOccurs=" " /> 

<xs:element name="ReferencedContentID" type= "ns : tRef erencedContentID" minOccurs=" " /> 
<xs:element name="ServiceState" type="ns : tServiceState" minOccurs="0"/> 
<xs:element name="ServiceStateInfonnation" type="xs : string" minOccurs= " " /> 
<xs:element name="ServiceStateExpireTime" type= "xs : dateTime " minOccurs= " " /> 

<xs:element name= "TrickPlayActivated" type= "xs : boolean" minOccurs=" " /> 
<xs:element name= " SSCRoomID" type= "xs : string" minOccurs= " " /> 
<xs:element name="PSCid" type= "xs : string" minOccurs= " " /> 

<xs:element name= " IPTVServiceState " type="ns : tIPTVServiceState" minOccurs= " " 
maxOccurs= "unbounded" /> 

<xs:any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tServiceState " > 
<xs : simpleContent> 

<xs : extension base= "ns : tServiceStateEnumeration" > 

<xs : attribute name=" extension" type="xs : string"/> 
< /xs : extens ion> 
</xs : simpleContent> 
</xs : complexType > 

<xs : simpleType name= " tServiceStateEnumeration" > 
<xs : restriction base= "xs : string" > 
<xs : enumeration value= " Play " /> 
<xs : enumeration value= " Pause " /> 
<xs : enumeration value= "Recording" / > 
<xs : enumeration value= " Fast - f orward" /> 
<xs : enumeration value= "Rewinding" / > 
<xs : enumeration value= " Picture- in-picture" /> 
<xs : enumeration value= "Extension" /> 
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</xs : restriction> 
</xs : simpleType> 

</xs : schema> 

NOTE: Here are two examples of tServiceState. 

<tServiceState>Play</tServiceState> 

<tServiceState extension= " Skipping" >Extension</tServiceState> 
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Annex F (informative): 

Example of presence information update after 
cliannel-cliange 



UE 



1. IGMP join 



Tec 



Core- 1 MS 



PS 



2. PUBLISH 



3. IPC 



4. PUBLISH 



5. 200 OK 



^. 200 (OK) 



Figure F.1 



1) IGMP Join request (UE to Core-IMS): 



The User wishes to change watching channel. The UE sends an IGMP join request to the multicast group 
corresponding to the selected channel. 

The timer Tec is started. 

2) PUBLISH request (UE to Core-IMS): 

After Tec timer expiration, to initiate the publication, the UE generates a PUBLISH request according to 
ES 283 030 [21]. 

The UE indicates the new watched channel in the present document. 

3) IPC: 

The S-CSCF routes the request to the Presence Server according to the IPC. 

4) PUBLISH request (Core-IMS to Presence Server): 

The Core-IMS forwards the PUBLISH request to the presence server thanks to the configured IPC. For 
example, for user 1 _public 1 @ homel.net the Core-IMS has originating initial Filter Criteria with Service Point 
Trigger of Method = PUBLISH AND Event = "presence" AND 

Request-URI = "sip:userl_pubUcl@homel.net" that informs the S-CSCF to route the PUBLISH request to the 
PS ps.homel.net. 

5) 200 (OK) response (PS to Core-IMS): 

The Presence Server evaluates the PUBLISH request and update presence information (i.e. currently watched 
channel). 



It replies with a SIP 200 OK to the Core IMS. 
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6) 200 (OK) response (Core-IMS to UE): 

The Core-IMS forwards the SIP 200 OK to the UE. 
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Annex G (informative): 

Example of presence document extension 

The following example describes the particular case of a BC service: 

<tuple id= " servll " > 
<status> 

<basic>open</basic> 
</status> 

<oma: service-description> 

<oma : service-id>IPTV-BC</oma : service-id> 
<oma: vers ion>x.y</oma: vers ion> 

<oma:description>IPTV Broadcast service</oma : description> 
</oma : service-description> 
<caps : servcaps> 

<caps :audio>true</caps :audio> 

<caps : video>true</caps : video 
</caps : servcaps> 
<BC> 

<currentBCServiceID>tv: BBCl . co . uk</currentBCServiceID> 

<currentBCProgramID>cid: the_weakest_link@bbcl . co .uk</currentBCProgramID> 

</BC> 

<rpid : class >IPTV</rpid : class > 
<dm : deviceID>mac : 8asd7d7d70</dm: deviceID> 
<note>commentl</note> 

</tuple> 

The following example describes the particular case of a BC service access history item: 
<tuple id="servl8"> 
<status> 

<basic>open</basic> 
</status> 

<oma: service-description> 

<oma : service -id>IPTV-SAH</oma : service -id> 
<oma : version>x . y< / oma : version> 

<oma:description>IPTV service access history</oma:description> 
</oma: service-description> 
<caps : servcaps> 

<caps :audio>true</caps :audio> 

<caps : video>true</caps : video> 
</caps : servcaps> 
<SAH> 

<ServiceType>BC</ServiceType> 

<Ref erencedContentID>tv; BBCl . co .uk</Ref erencedContentID> 
<Rating>2</Rating> 

<AccessStartTime>2009-08-06T20 : 08 : 00</AccessStartTime> 
<AccessEndTime>2009-08-06T20 :40 : 25</AccessEndTime> 
<HistoryExpireTime>PT24H</HistoryExpireTime> 
</SAH> 

<rpid: class>IPTV</rpid: class> 
<dm: deviceID>mac : 8asd7d7d70</dm: deviceID> 
<note>commentl</note> 
</tuple> 
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Annex H (informative): 

Summary of standards and protocols for IIVIS based IPTV 

This informative annex provides summary of standards and protocols version (specification compliance) required by 
IMS based IPTV in mentioned reference points. 

NOTE: In case of any inconsistencies with the normative text, the normative text applies. 



H.1 SIP/SDP protocol 



Usage the SIP/SDP protocol across the following reference points is described in clause 5: 

reference point Gm; 

reference point ISC; 

reference point y2. 
Following functional entities are SIP/SDP capable: 

UE, SCF, SDP, MCF, Core IMS. 
Following SIP protocol model explain which SIP request method are used for particular procedure. 



ISC 




SCF 




Core IMS 



y2 



MCF 



Figure H.1 : IMS based IPTV - SIP protocol model 

A. UE send REGISTER to Core IMS and SDF. 

B. Service discovery Push mode - SDF send message MESSAGE with discovery information. 

C. Service discovery Pull mode - UE used SUBSCRIBE to SDF over Core IMS, SDF send NOTIFY with service 
discovery information (also when changed). 

D. Service initiation, modification and teardown from UE via Core IMS to SCF (INVITE, re-INVITE or 
UPDATE, BYE). 
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E. UE sends a SIP MESSAGE request to SCF requiring NPVR service (SCF send MESSAGE to MCF). 

F. Optional - procedures for join multicast group (clause 8.1.1) the UE may inform SCF of the selected channel 
(sending INFO message). 

G. INFO message to send COD Service action data information to SCF. 

H. Service Attachment - PULL mode is used SUBSCRIBE and NOTIFY methods. 

I. Optional - Presence used for channel watching information. 

H.1 .1 Protocol specifications used for SIP/SDP 

This clause contains list of protocol specifications required for IMS based IPTV implementation used as references in 
clause 5 or other related to SIP/SDP specifications. This clause contains also summary of methods required for 

implementation as mandatory and also optional. 

Several Core IMS procedures are explicitly used by IMS based IPTV (not limited) hke IMS registration, session 
initiation, modification and termination. 

SIP methods like REGISTER, INVITE, UPDATE, PUBLISH, NOTIFY, MESSAGE, SUBSCRIBE are used in IMS 
based IPTV. 

The following tables explain relation of used specification for specified function entity towards other entities. Last 
column summarizes requirements for implementation for specified functional entity (which specification are required 
for implementation). 



Table H.1 : SIP/SDP protocol related specification for UE 



Specifications for: 
UE 


iMS core 


SDF 


SCF 


iUICF 


Summary of required 
impiementation 


Ref. point 


Gm <-> 


Via IMS core 

<-> 


Via IMS core 
<-> 




UE 


REGISTER [20] 


(M) 


(M) 
3rd party 






(M) 


INVITE, re-INVITE or UPDATE, 
BYE [20] 


(M) 




(M) 




(M) 


MESSAGE [23] and [20] 
IVIESSAGE is used only by "Push 
mode" service discovery and "N- 
PVR" service 






(M) 




(M) 


PUBLISH [21] for 

IPTV presence (optional) 






(0) 




(0) 


SUBSCRIBE [20] 
Pull mode 




(M) clause 
5.1.2A.1 






(M) 


NOTIFY [25] 
In pull mode 






(M) 




(M) 


SIP INFO [20] 






(0) 




(0) 


Annex Y 
in pull mode 






(M) 




(M) 


0MA-TS-Presence-SIIVIPLE-V1 [23] 






(0) 




(0) 


RFC 5875 [26] 






(0) 




(0) 


RFC 5874 [15] 






(0) 




(0) 
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Table H.2: SIP/SDP protocol related specification for Core IMS 



Specification: 
IIUIS core 


UE 


SDF 


SCF 


MCF 


Summary of required 
implementation 


Ref. point 


Gm <-> 


ISC <-> 


ISC <-> 


y2 <-> 


IMS core 


ES 283 003 [20] 


(M) 


(M) 
ISC 


(M) 
ISC 


(M) 


Core IMS entities 


REGISTER, INVITE [20] 


(M) 


(M) 






(M) 


NOTIFY [25] [29] 
Pull mode 


(M) 


(M) 






(M) 


NOTE: Table mentions just SIP methods explicitly used in IMS based IPTV procedures but does not exclude any 
ottier usage of other methods. 



Table H.3: SIP/SDP protocol related specification for SDF 



Specification: SDF 


UE 


IMS core 


SCF 


MCF 


Summary of required 
implementation 


Ref. point 


Push mode -> 
Pull mode <-> 
Via IMS core 


ISC <-> 






SDF 


REGISTER [20] 










third-party registration 


Push mode [20] 


(M) 








(M) 


Pull mode 
NOTIFY [29] 


(M) 

clause 5.7.1.4 








(M) 

clause 5.7.1.4 


Pull mode 
user's identity 
verification [29] 


(M) 








(M) 



Table H.4: SIP/SDP protocol related specification for SCF 



Specification: SCF 


UE 


IMS core 


SDF 


MCF 


Summary of required 
implementation 


Ref. point 


Ut <-> 


ISC <-> 


Via IMS core 


Via IMS core 


SCF 


ES 283 003 [20] 










SCF act as an AS acting as a 
terminating UA for BC service 
or SCF act as an AS acting as 
an originating UA for BC 
service 

SCF act as a B2BUA when N- 
PVR service is used (SIP 
dialog Is established 
UA<=>SCF and SCF<=> 
MCF) 

SCF is a proxy or a B2BUA 
when CoD service is used 


INVITE, re-INVITE or 
UPDATE, BYE [20] 




(M) 




(M) 


(M) 

Via IMS core 



Table H.5: SIP/SDP protocol related specification for MCF 



Specification: MCF 


UE 


IMS core 


SDF 


SCF 


Summary of 
required 
implementation 


Ref. point 




y2 <-> 




Via IMS core 


MCF 


ES 283 003 [20] 




(M) 




(M) 


MCF act as a 
generic terminating 
UA 

(M) 


REDIRECT SIP [2] 
BC with Trick play 




(M) 




(M) 


(0) 

clause 5.1 .3.3 



ETSI 



174 



ETSI TS 183 063 V3.5.1 (2011-02) 



H.2 HTTP protocol 

Usage of the HTTP protocol across the following interfaces is described in clause 6: 

interface Xa; 

interface Ut. 
HTTP capable functional entities: 

UE, SCF, SSF. 



Table H.6: Summary of specifications compliancy for HTTP capable FEs 



Specification: 


UE 


SSF 


SCF 


RFC 4825 [9] 


XCAP Client (M) 


NA 


XCAP sever (M) 

HTTP PUT, HTTP GET or 

HTTP DELETE 


RFC 5246 [32] 


(M) 


(M) 


(M) 


TS 187 003 [10] 


(M) 


(M) 


NA 


TS 124 109 [11] 


NA 


(0) 


(0) 


TS 183 023 [12] 


NA 


(0) 


(0) 


TS 1 02 034 [3] 


clause 5.4.2.2 (M) 


clause 5.2.6 (M) 


NA 


TS 1 02 539 [1 3] 


clauses 4.1 .2.2.2 and 4.2 (M) 


clauses 4.1.2 and 4.2 (M) 


NA 


TS 133 222 [14] 


(0) 


(0) 


NA 


RFC5874 [15] 


(0) 


NA 


(0) 


OMA OMA-TS- 
BCAST Service Guide- 
V1 0[6] 


clause 5.4.3 (M) 


clause 5.4.3.3 (M) 


NA 


NOTE: (M) - Mandatory. 
(0) - Optional. 
NA - NOT Applicable. 



H.3 RTSP/SDP protocol 

Usage of the RTSP/SDP protocol across the following interfaces is described in clause 7: 

interface Di, Dj, Ds or Iz. 
RTSP/SDP capable functional entities: 

UE, MCF. 

H.3.1 Protocol specifications used for RTSP/SDP 

This clause contain summary of RTSP methods required for implementation in IMS based IPTV as mandatory or 
optional (as references to clause 7 or other related to RTSP). Table H.7 shows the differences by using RTSP method in 
compare with RFC 2326 [8]. 
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Table H.7 



RTC^P lUlAthnH 
n 1 Or ividiiuu 


r)iKor*tirtn ■ 

C = client - 

UE; 
S = Server 
-MCF; 


RFC 9'*9fi FRI 


DVB Requirement 
TBI 02 034 [3] 


TISPAN 
IMS based IPTV 








LMB 


MBwTM and 

IVI VV 1 IVI Ql Ivl 

CoD 


Method 1 


Method 2 


ANNOUNCE 


C^S 


MAY 


MAY 


MAY 


N.A. 


N.A. 


ANNOUNCE 


S^C 


MAY 


SHOULD 


SHOULD 


(M) 


(M) 


DESCRIBE 


C^S 


SHOULD 


SHOULD 


SHOULD 


N.A. 


(M) 


GET_PARAMETER 


C^S 


MAY 


SHOULD 


SHOULD 


(M) 


N.A. 


GET_PARAMETER 


s^c 


MAY 


MAY 


MAY 


N.A. 


N.A. 


OPTIONS 


c^s 


SHALL 


SHALL 


SHALL 


(M) 


N.A. 


OPTIONS 


s^c 


MAY 


MAY 


MAY 


N.A. 


N.A. 


PAUSE 


c^s 


SHOULD 


N.A. 


SHALL 


(M) 


(M) 


PLAY 


c^s 


SHALL 


SHALL 


SHALL 


(M) 


(M) 


REDIRECT 


s^c 


MAY 


SHALL 


SHALL 


N.A. 


N.A. 


SETUP 


c^s 


SHALL 


SHALL 


SHALL 


N.A. 


(M) 


TEARDOWN 


c^s 


SHALL 


SHALL 


SHALL 


N.A. 


(M) 


SET_PARAMETER 


c^s 


MAY 


N.A. 


N.A. 


(M) 


N.A. 


SET_PARAMETER 


s^c 


MAY 


N.A. 


N.A. 


N.A. 


N.A. 


RECORD 


c^s 


MAY 


N.A. 


N.A. 


N.A. 


N.A. 


NOTE: (M) = Mandatory. 
(0) = Optional. 
N.A. = Not Applied. 

The text in bold shows differences comparing to RFC 2326 [8] table 2. 



H.4 UDP/RTP/RTCP protocol 

Usage of the UDP/RTP/RTCP protocol across the following interfaces is described in clause 11: 

interface Xd; 

interface Di, Dj, Ds or Iz. 
UDP/RTP/RFTCP capable functional entities: 

UE, MDF, MSAS, SC, SC. 



H.5 IGMP/MLD protocol 

Usage of the IGMP/MLD protocol across the following interfaces is described in clause 8: 

interface Dj, Di, Ds, or Iz. 
IGMP/MLD capable functional entities: 

UE, Transporting functions (ECF/EFF), MDF. 
If IPv4 is used for the transport, the UE conforms to RFC 3376 [28] (IGMPv3). 
If IPv6 is used for the transport, the UE conforms to RFC 3810 [29] (MLDv2). 

Backward compatibility rules between the UE and the Transport Fimction have to be done conforming to 
RFC 3376 [28], clause 7 and RFC 3810 [29], clause 8. 
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UE need to support at least: 

IGMP v3 unsolicited Membership Report or a MLDv2 Multicast Listener Report Message. 
IGMP v3 Membership Report Message or MLD v2 Multicast Listener Report Message. 

H.6 Diameter protocol 

Use of Diameter complies to the following specifications: 

TS 183 017 [i.2] in case of the Gq' interface. 

ES 283 035 [36] in case of the e2 interface. 

TS 183 033 [i.3] in case of the Cx and Dx' interfaces. 

TS 1 29 329 I i.4 1 in case of the Sh and Dh interfaces. 
Diameter capable functional entities: 

CorelMS, SCF, SDF. 

H.7 DVBSTP protocol 

Usage of the DVBSTP protocol across the following interface is described in clause 9: 

interface Xa. 
DVBSTP capable functional entities (Optionally): 

UE, SSF. 



H.8 FLUTE protocol 

Usage of the FLUTE protocol across the following interface is described in clause 10: 

interface Xa. 
FLUTE capable functional entities (Optionally): 

UE, SSF. 
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Annex I (normative): 

Procedures for discovery of SDFs prior to service 
attaclnment 

This annex describes a set of alternatives for the UE to identify the SDFs and/or the service provider domain 
information associated with them prior to service attachment procedures. 

The order in which these ahernatives are executed or priority between the ahernatives when executed simultaneously is 
outside of the scope of the present document. 



1.1 Manual configuration based manual discovery 

The UE may be manually configured with the one or more instances of the following information. 

• The Service Provider Name: This provides the name of the Service Provider to connect to first. It is of variable 
length. 

• ServiceProviderDomainName: This provides the domain name corresponding to Service provider. It is of 
variable length. 

• ServiceDiscoveryServer: This specifies the address of the SDF associated with the SP and it is specified as an 
IMS Public Service Identifier or IP address or URL. 

• The IMS PSI value shall be specified for IMS-based Service Discovery Function. 

• The IP Address or URL may be specified for non-SIP-AS based Service Discovery Function. 



1.2 DHCP-based discovery 

In addition to acquiring its IP address from the DHCP server, in this mechanism the UE can acquire information on 
SDFs and associated Service Provider(s) information using appropriate vendor class identifier DHCP options. 

1.2.1 Using DHCP option 43/60 

The client may send a Vendor class Identifier DHCP option 60 as specified in ES 283 003 [20] when it requests a 
DHCP lease for server. The option is specified with the vendor-class identifier as "ETSI_TISPAN_IPTV_SDS". 

The DHCP server delivers the SDF information via Vendor-Specific Information DHCP option 43 packed in a binary 
buffer as defined in ES 283 003 [20]. The format of the binary buffer containing the SDF information is specified in 
clause 1.2.3. 

1.2.2 Using DHCP option 124/125 

This vendor identifier specific DHCP option is recommended to be used when there is a need to support DHCP options 
from multiple vendors as specified in RFC 3925 [17]. 

The client may send a Vendor -Identifying Vendor Class option 124 as specified in RFC 3925 [17] when it requests a 
DHCP lease for server. The option is specified with an enterprise-number of 13019 (ETSI) and the vendor-class-data 
identifier as "ETSI_TISPAN_IPTV_SDS". 

The DHCP server delivers the SDF information via Vendor-Identifying Vendor-Specific Information DHCP option 125 
packed in a binary buffer as defined in RFC 3925 [17]. The enterprise-number shall be set as 13109 (ETSI). The format 
of the binary buffer containing the SDF information is specified in clause 1.2.3. 
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1.2.3 Format of DHCP payload 

The format of the vendor- specific binary buffer containing SDF addresses returned by the DHCP server is as follows. 
It is a list of sub-options starting with sub-option number (one byte), its length (one byte) and its value (hst of bytes). 
The following vendor-specific sub-options are defined: 

• Sub-Option: IMS_IPTV_SP: Code = 0x01 . This option provides the name of the Service Provider to connect 
to first. It is of variable length and it is Optional. 

• Sub-Option: IMS-IPTV-SPDOMAIN: Code= 0x02. This option provides the domain name corresponding to 
Service provider. It is of variable length and it is Optional. 

• Sub-Option: IMS-IPTV-SDF: Code=0x03. This option carries either the (1) IMS PSl value, (2) the IPAddress 
of SDF or (3) the fully-quaUfied domain name of the Service Discovery Server associated with the Service 
Provider. This is Mandatory. 

• A one byte "enc" field is used to indicate the type of encoding. 

If the "enc" field has a value of _OxOO, then this indicates an IMS PSI value. The "enc" field is followed 
by the bytes corresponding to the IMS PSI. This value shall be used for IMS-based service discovery 
function. 

If the "enc" field has a value of _0x01, then this indicates an IP Address. The "enc" field is followed by 
4 bytes corresponding to the IPAddress. This value may be used for non-SIP AS service discovery 
function. 

If the "enc" field has a value of 0x02, then this indicates a DNS hostname. The "enc" field is followed by 
a sequence of labels, encoded according to clause 3.1 of RFC 1035 [18]. This value maybe used for 
non-SIP AS service discovery function. 

• The code of OxFF is used to indicate end of the buffer. 

The availability of the service provider SDF information at the Network Provider DHCP server is subject to business 
policies between the service provider and network provider. 



1.3 DNS Service Records (SRV) - based discovery 

In this case, the SD servers are discovered using the DNS SRV mechanism in accordance with RFC 2782 [31], with the 

following input parameters: 

• Service: Defined as "tispan-iptv-service". This is the symbolic name of the desired service; to be defined and 
registered with lANA. 

• Protocol: Can take values "http" or "sip". Specifies the protocol to contain the particular service. 

• Domain name: the domain for which the returned records are valid; the value can be derived from the 
following: 

Domain from manual configuration. 

Domain from network attachment phase (DHCP server). 

Domain from IMS home domain. 

The output of the DNS SRV lookup is an ordered Ust of domain name, each pointing to a SDF server available within 
the specified Domain name. 



ETSI 



179 



ETSI TS 183 063 V3.5.1 (2011-02) 



1.4 TR-069 based discovery 

In this case, the UE discovers the addresses of the SDFs and associated Service Provider information during remote 
configuration procedures using the TR-069 [37] protocol. 

Specifically, upon successful UE network attachment and successful creation of a management session with the remote 
configuration server, the CNGCF may provide the UE with a listing of IPTV service providers and associated SDF 
servers that it knows about. How the remote configuration server at the CNGCF is provided with this information is 

beyond the scope of the present document. 

An ordered listing of one or more instances of the following elements may be delivered: 

• The Service Provider Name: This provides the name of the Service Provider to connect to first. It is of variable 
length. 

• ServiceProviderDomainName: This provides the domain name corresponding to Service provider. It is of 
variable length. 

• ServiceDiscoveryServer: This specifies the address of the SDF associated with the SP and it is specified as an 
IMS Public Service Identifier or IP address or URL: 

The IMS PSI value shall be specified for IMS-based Service Discovery Function. 

The IPAddress or URL may be specified for non-SIP-AS based Service Discovery Function. 

NOTE: The exact object extension used to carry the above information during remote configuration is beyond 
scope of the present document. 
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Annex J (informative): 

Integration of non SIP AS service discovery function 

J.1 Integration of non SIP AS service discovery Function 
based on DVB IPTV 

J.1 .1 User Equipment (UE) 

J.1 .1 .1 Procedure for service attachment 

In order to discover the list of SDF, the UE will foUow the entry points discovery steps as defined in TS 102 034 [3], 
clause 5.2.4. 

The UE will use HTTP or DVBSTP protocols in order to retrieve the service provider discovery information, 
conforming to TS 102 034 [3], clause 5.4. 

NOTE: It is also possible that the UE holds a hard-coded parameter containing the entry point information, or that 
an out-of-band mechanism exists for the UE to retrieve this information. 

J . 1 . 1 .2 Procedure for service selection 
J. 1.1. 2.1 Request of DVB SD&S 

The UE will use HTTP or DVBSTP protocols in order to retrieve the SD&S information, conforming to 
TS 102 034 [3], clause 5.4. 

J.1. 1.2.2 Request of DVB BOG 

The UE will use HTTP, DVBSTP or HTTP/SOAP protocols in order to retrieve the BCG information, conforming to 
TS 102 539 [13], clause 4. 

J.1 .2 Service Discovery Function (SDF) 
J.1 .2.1 Procedure for service attacliment 

The SDF will provide to the UE the service provider discovery information conforming to TS 102 034 [3J, 
clause 5.2.5. 

The SDF will use HTTP and DVBSTP protocols, conforming to TS 102 034 [3], clause 5.4. 

J. 1.3 Service Selection Function (SSF) 

J . 1 .3. 1 Procedure for service selection 

J. 1.3. 1.1 Delivery of DVB SD&S 

The SSF will provide to the UE the SD&S information conforming to TS 102 034 [3], clause 5.2.6. 
The SSF will use HTTP and DVBSTP protocols, conforming to TS 102 034 [3], clause 5.4. 
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J.1 .3.1 .2 Delivery of DVB BCG 

The SSF will provide to the UE the BCG information conforming to TS 102 539 [13]. 

The SSF will use HTTP, DVBSTP, and HTTP/SOAP protocols, conforming to TS 102 539 [13], clause 4. 



J. 2 Integration of non SIP AS service discovery function 
based on OMA BCAST ESG 

J.2.1 User Equipment (UE) 

J. 2.1 .1 Procedure for service attachment 

It is assumed that each service provider publishes a single ESG. Thus, an ESG provider is equal to a service provider. 
For discovering the available service providers the list of SDFs, the UE can follow the ESG bootstrapping method as 
defined in OMA-TS-BCAST_DVB_Adaptation-Vl_0 [7], clause 6.3.5 or other signalling methods. It is assumed that 
there is an ESG bootstrap session where service guides are described with ESGProviderDiscovery Descriptors, as 
specified in clause 9 of TS 102 471 [4]. This also applies to describing OMA BCAST service guides [6]. In the push 
situation, the ESG bootstrap session will be a FLUTE session as specified in TS 102 471 [4]. In the puU situation, the 
bootstrap session uses HTTP. 

NOTE: It is also possible that the UE holds a hard-coded parameter containing the entry point information, or that 
an out-of-band mechanism exists for the UE to retrieve this information. 

J .2. 1 .2 Procedure for service selection 

J. 2.1 .2.1 Request of ESG provider discovery information 

The UE uses the FLUTE protocol in order to retrieve the ESGProviderDiscovery Descriptor information, conforming to 
TS 102 471 [4], clause 9.2 and OMA-TS-BCAST_DVB_Adaptation-Vl_0 [7], clause 6.3.5 or it uses the HTTP 
protocol. 

J.2.1 .2.2 Request of OMA BCAST ESG 

The UE uses HTTP or FLUTE protocols in order to retrieve the ESG information, conforming to TS 102 471 [4], 
clause 8.1, OMA-TS-BCAST_DVB_Adaptation-Vl_0 [7], clause 6.3.5 and OMA-TS-BCAST_Service_Guide-Vl [6], 
clause 5.4. 

J.2.2 Service Discovery Function (SDF) 
J. 2.2.1 Procedure for service attachment 

The SDF will provide to the UE the service provider discovery information in the form of ESGProviderDiscovery 
Descriptors, conforming to TS 102 471 [4], clause 9.1.1. 

For providing the UE with this information, the SDF will use HTTP and FLUTE protocols, conforming to 
TS 102 471 L4J, clause 9.2, OMA-TS-BCAST_DVB_Adaptation-Vl_0 [7], clause 6.3.5 and 
OMA-TS-BCAST_Service_Guide-Vl [6], clause 5.4. 
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J.2.3 Service Selection Function (SSF) 

J. 2. 3.1 Procedure for service selection 

J. 2.3.1 .1 Delivery of ESG provider discovery information 

The SSF will provide to the UE the ESGProviderDiscovery Descriptor conforming to TS 102 471 [4], clause 9.1.1. The 
SSF use thes FLUTE protocol, conforming to TS 102 471 [4], clause 9.2 and 
OMA-TS-BCAST_DVB_Adaptation-Vl_0 [7], clause 6.3.5. or it uses the HTTP protocol. 

J.2.3.1.2 Delivery of OMA BCAST ESG 

The SSF wiU provide to the UE the ESG information conforming to 
OMA-TS-BCAST_Service_Guide-Vl_, clause 5.4. 

The SSF will use HTTP or FLUTE protocols, conforming to TS 102 471 [4], clause 8.1, 

OMA-TS-BCAST_DVB_Adaptation-Vl_0 [7], clause 6.3.5 and OMA-TS-BCAST_Service_Guide-Vl [6], clause 5.4. 



ETSI 



183 



ETSI TS 183 063 V3.5.1 (2011-02) 



Annex K (normative): 

XML Schemas for the IPTV service action data 

This annex specifies XML schemas for creating documents representing instances of the IPTV service action data. 
XML Schema for BC service related data: 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 

<xs : schema targetNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvbcserviceactiondata" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvbcserviceactiondata" 
xmlns : xs= "http : //www . w3 . org/2 01/XMLSchema" elementFormDefault= "qualified" 
attributeFormDef ault= " unqualified" > 

<xs : element name= " IPTVBcActionData" > 
<xs : complexType> 

<xs : sequence> 

<xs:element name= "BCBookmark" type="tBCBookmark" minOccurs= " " 
maxOccurs= " unbounded" / > 
</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : complexType name= " tBCBookmark" > 
<xs : sequence> 

<xs: element name="BCServiceId" type= "xs : string" /> 

<xs:element name="ProgrammeId" type= "xs : string" minOccurs= " " /> 

<xs:element name=" Bookmark" type= "xs : dateTime" /> 

<xs: element name="BookmarkExpiryTime" type= "xs : dateTime" minOccurs= " " /> 
<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " 

maxOccurs= "unbounded" / > 

</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tExtension" > 
<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 
</xs : schema> 



XML Schema for CoD service related data: 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 

<xs : schema targetNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvcodserviceactiondata" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvcodserviceactiondata" 
xmlns : xs= "http : //www . w3 . org/2 01/XMLSchema" elementFormDefault= "qualified" 
attributeFormDef ault= " unqualified" > 

<xs : element name="IPTVCodActionData" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="AvailableCoD" type="tAvailableCoD" minOccurs= " " 
maxOccurs= " unbounded" / > 

</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : complexType name="tAvailableCoD" > 
<xs : sequence> 

<xs: element name="CoDId" type= "xs : string" / > 

<xs : element name= " CoDDeliveryStatus " type= " tCodDeliveryStatus " / > 
<xs:element name= " CoDOf f set " type= "xs : string" minOccurs= " " /> 
<xs:element name="CoDOf f setExpiryTime" type= "xs : dateTime" minOccurs= " " / > 
<xs:element name="Extension" type= " tExtension" minOccurs= " " / > 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 

<xs : attribute name= " expectedDuration" type= "xs : duration" use= "optional "/ > 
</xs : complexType > 

<xs : simpleType name= " tCodDeliveryStatus " f inal= " list " > 
<xs : restriction base="xs :unsignedByte" > 
<xs : minlnclusive value="0"/> 
<xs : maxinclusive value="4"/> 
<xs : enumeration value="0"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Ordered</label> 

<definition xml : lang= " en" >Content has been ordered</def inition> 
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</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="l"> 
<xs : annotation> 

<xs : documentation> 

< label xml : lang= " en" >Ongoing</ label > 

<definition xml : lang="en" >Streaming delivery has started</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="2"> 
<xs : annotation> 

<xs : documentation> 

< label xml : lang= " en" >Failed</ label > 

<definition xml : lang= " en" >Some error has occurred while delivering the 

content</def inition> 

</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="3"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Parked</label> 

<definition xml : lang= " en" >The content was parked and will be pickep up 

later</def inition> 

</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="4"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Paused</label> 

<definition xml : lang="en" >The content is paused for the amount of time 
indicated by the expectedDuration attribute</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name= " tExtension" > 
<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence > 
</xs : complexType> 
</xs : schema> 



XML Schema for N-PVR service related data: 



<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

<xs : schema targetNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvnpvrserviceactiondata" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvnpvrserviceactiondata" 



xmlns :xs="http : //www. w3 . org/2 1/XMLSchema" 
attributeFormDef ault= " unqualified" > 

<xs : element name= " IPTVNpvrActionData" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name= "NPVRItem" 
</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : complexType name= " tNPVRItem" > 
<xs : sequence> 

<xs: element name= "NPVRContentId 



elementFormDef ault= " qualified" 



type= " tNPVRItem" minOccurs= " " maxOccurs= "unbounded" / > 



'0 



7> 
'0"/ = 



7> 



type= "xs : string" minOccurs= 
<xs: element name="BCServiceId" type= "xs : string" /> 
<xs: element name="RecordStartDate" type= "xs : string" minOccurs= 
<xs:element name="RecordEndDate" type= "xs : dateTime" minOccurs= " " / > 
<xs:element name="RecordStatus" type= " tRecordStatus " minOccurs= " " / > 
<xs:element name="PlaybackOf f set" type= "xs : string" minOccurs= " " / > 
<xs:element name="PlaybackOf f setExpiryTime" type= "xs : dateTime" minOccurs = " '' 
<xs:element name="NPVRContentExpiryTime" type= "xs : dateTime" minOccurs= " " / > 
<xs: element name= " Extension" type= " tExtension" minOccurs= " " / > 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs="unbounded"/> 
</xs : sequence > 
</xs : complexType > 

<xs : simpleType name= " tRecordStatus " > 

<xs : restriction base= "xs : unsignedByte" > 
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<xs : minlnclusive value="0"/> 
<xs : maxinclusive value="3"/> 
<xs : enumeration value="0"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Scheduled</label> 

<definition xml : lang= " en" >Recording is scheduled</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="l"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Started</label> 

<definition xml : lang= " en" >Recording has started</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="2"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Available</label> 

<definition xml : lang= " en" >Recording is available</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="3"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Failed</label> 

<definition xml : lang= " en" >Recording has f ailed</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name= " tExtension" > 
<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 
</xs : schema > 



XML Schema for CPVR service related data: 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

<xs : schema targetNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvcpvrserviceactiondata" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvcpvrserviceactiondata" 
xmlns : xs= "http : //www . w3 . org/2 01/XMLSchema" elementFormDefault= "qualified" 
attributeFormDef ault= " unqualified" > 

<xs : element name= " IPTVCpvrActionData" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="CPVRItem" type="tCPVRItem" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 



<xs : complexType name= " tCPVRItem" > 
<xs : sequence> 

<xs:element name="CPVRContentId" type= "xs : string" minOccurs= " " /> 
<xs: element name="BCServiceId" type= "xs : string" /> 
<xs: element name="TargetUEId" type= "xs : string" /> 

<xs:element name="RecordStartDate" type= "xs : string" minOccurs= " " / > 
<xs:element name="RecordEndDate" type= "xs : dateTime" minOccurs= " " / > 
<xs: element name="RecordStatus" type= " tRecordStatus " minOccurs= " " /> 
<xs:element name= " Extension" type= " tExtension" minOccurs= " " /> 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name= "tRecordStatus " > 

<xs : restriction base= "xs : unsignedByte" > 
<xs : minlnclusive value="0"/> 
<xs : maxinclusive value="3"/> 
<xs : enumeration value="0"> 
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<xs : annotation> 

<xs : documentation> 

< label xml : lang= "en" >Scheduled</label > 

<definition xml : lang="en" >Recording is scheduled</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="l"> 
<xs : annotation> 

<xs : documentation> 

< label xml : lang= "en" >S t art ed</ label > 

<definition xml : lang="en" >Recording has started</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="2"> 
<xs : annotation> 

<xs : documentation> 

< label xml : lang= "en" >Available</label> 

<definition xml : lang="en" >Recording is available</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="3"> 
<xs : annotation> 

<xs : documentation> 

< label xml : lang= "en" >Failed</label > 

<definition xml : lang="en" >Recording has f ailed</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name= " tExtension" > 
<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 
</xs : schema> 



XML Schema for UGC service related data: 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 

<xs : schema targetNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvugcserviceactiondata" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvugcserviceactiondata" 
xmlns : xs= "http : //www . w3 . org/2 01/XMLSchema" elementFormDefault= "qualified" 
attributeFormDef ault= " unqualified" > 

<xs : element name= " IPTVUGCActionData" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name= "UGCItem" type= " tUGCItem" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 

<xs : attribute name= "message- id" type= "xs : string" /> 
</xs : complexType > 
</xs : element > 

<xs : complexType name= " tUGCItem" > 
<xs : sequence> 

<xs: element name="UGCContentId" type= "xs : string" minOccurs= " " / > 

<xs:element name="UGCCreationTime" type= "xs : dateTime" minOccurs= " " / > 

<xs:element name="UGCGenre" type= "xs : string" minOccurs= " " /> 

<xs:element name="UGCTitle" type= "xs : string" minOccurs= " " / > 

<xs: element name="UGCOriginator" type= "xs : string" minOccurs= " " / > 

<xs: element name="UGCDescription" type= "xs : string" minOccurs= " " / > 

<xs: element name="UGCAuthorizedViewUser" type= "xs : string" minOccurs= " " / > 

<xs: element name= "Extension" type= " tExtension" minOccurs= " " / > 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / ; 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tExtension" > 
<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 
</xs : schema> 
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XML Schema for Content Insertion service related data: 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 

<xs : schema targetNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvcontent insert ionserviceactiondat a" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvcontent insert ionserviceactiondat a" 
xmlns : xs= "http : //www . w3 . org/2 01/XMLSchema" element FormDefault= "qualified" 
attributeFormDef ault= " unqualified" > 

<xs : element name= " IPTVContentlnsertionActionData" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name= " InsertionData" type="tInsertionData" minOccurs= " " 
maxOccurs= " unbounded" / > 

</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : complexType name="tInsertionData" > 
<xs : sequence> 

<xs: element name= " IPTVContentldentif ier " type= "xs : string" / > 
<xs:element name= " InsertedContentldentif ier " type= "xs : string" /> 
<xs:element name= " InsertionTime" type= "xs : dateTime" minOccurs= " " / > 
<xs:element name= " InsertionStatus " type= " tInsertionStatus " / > 
<xs:element name="Extension" type= " tExtension" minOccurs= " " / > 

<xs:any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name= "tInsertionStatus " > 
<xs : restriction base= "xs : string" > 

<xs : enumeration value= "Accepted" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= " en" >Insertion is accepted</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 

<xs : enumeration value= "Re j ected" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= " en" >Insertion is rej ected</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value= " Started" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= " en" >Insertion has started</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 

<xs : enumeration value= " Finished" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= " en" >Insertion is f inished</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value= " Failed" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= " en" >Insertion has f ailed</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name= " tExtension" > 
<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 
</xs : complexType> 
</xs : schema> 



XML Schema for PCh service related data: 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 

<xs : schema targe tNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvpchserviceact iondata" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvpchserviceact iondata" 
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xmlns : xs= "http : / /mm . w3 . org/2 001/XMLSchema" elementFormDefault = "qualified" 
attributeFormDefault= "unqualified" > 

<xs : element name= " IPTVPChActionData" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name= " PChList " type= " tPChList " minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 

<xs : attribute name= " transaction- id" type= "xs : string" use= "optional "/ > 
</xs : complexType> 
</xs : element > 

<xs : complexType name= "tPChList " > 
<xs : sequence> 

<xs:element name= " PChltem" minOccurs= " 1 " maxOccurs= " unbounded" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name="PChItemServiceType" type= "xs : string" /> 
<xs:element name="PChItemContentId" type= "xs : anyURI " /> 
<xs:element name="PChItemStartTime" type= "xs : dateTime" /> 
<xs:element name="PChItemEndTime" type= "xs : dateTime" /> 
<xs: element name= " PChltemOf f set " type= "xs : duration" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 

<xs : attribute name="PChId" type= "xs : anyURI " use= " required" / > 
</xs : complexType> 
</xs : schema> 
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Annex L (normative): 

Mapping of IPTV parameters to service selection 
L.1 IVIapping of service attachment 

This clause presents how several IPTV technologies are mapped into TISPAN metadata (XML schema as specified in 
annex M) concerning the discovery of SSF entities. In the current release DVB and OMABCAST technologies mapping 
are described. 

Within the XML schema, some fields are specific to TISPAN, they are marked as "TISPAN defined field" in the 
following tables. 

L.1 .1 Mapping of DVB SD&S SP discovery records to XML 
Schema for Service Attachment 

This clause describes the mapping of DVB SD&S Service Provider discovery record to the generic XML schema for 
service attachment defined in annex M and clause 5.2.2.3. 



TISPAN Element Name 
(copied from clause 5.2.2.3) 


Corresponding DVB SD&S element In TS 102 034 [3], 
clause 5.2.5, table 2 
(TS 102 034 [3] XML Schema clause reference) 


SSF 




@ID 


TISPAN defined field 


©Technology 


when a DVB SSF is advertised, this field must be "dvb.org iptv" 


^CW VclblUl 1 


1 ixjrMiv utti 11 tcu nttiu 


Description 


1 lijrAN oeTineci rieio 


^pn/ippPrnv/irlpr 

od V iLrC r 1 U V lUCl 


^pr\/ippPrn\/iHp»r 

(Clause C. 1.4.6) 


(SDomainName 


ServiceProvider@DomainName 
(Clause C.1.4.6) 


@LogoURI 


ServiceProvider@LogoURI 
(Clause C.1.4.6) 


Name 


ServiceProvider.Name 
(Clause C.1.4.6) 


Description 


ServiceProvider. Description 
(Clause C.1.4.6) 


Pull 


Off e ri ng Li stTy pe . P u 1 1 
(Clause C.I. 3.1 5) 


©Location 


Pull@Location 
(Clause C.I. 3.15) 


DataType 


Payloadid 

There is a direct mapping between the DVB Payloadid values and this 
field. 

(Clause C.I. 3.19) 


@Type 


Payloadld@ld 

refer to table 1 in TS 1 02 034 [3] and to table 2 in TS 1 02 539 [1 3] 
TS 1 02 034 [3] defines the values 0x00 to 0x06, 
TS 102 539 [13] defines the values OxAl to 0xA7. 
The present specification defines an additional value OxAO: when 
using OxAO, it means that the Pull@Location URL refers to an SSF 
that is a DVB-BCG server using the SOAP protocol, instead of the 
pull HTTP delivery. When OxAO is used, no Segment element shall 
be exposed. 
(Clause C.I. 3.1 9) 


Segment 


Payloadid. Segment 
(Clause C.I. 3.1 9) 

This parameter is mandatory for DVB Pull mode 


@ID 


Payloadid. Seament@ld 


(Clause C.I. 3.19) 
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TISPAN Element Name 
(copied from clause 5.2.2.3) 


Corresponding DVB SD&S element in TS 102 034 [3], 
clause 5.2.5, table 2 
(TS 102 034 [3] XML Schema clause reference) 


(©Version 


Pavloadld.Seqment(3)Version 


(Clause C.1.3.19) 


Push 


OfferingListType.Push 
(Clause C.1.3.15, C.1.3.4) 


@IPVersion 




@MulticastAddress 


©Address 
(Clause C.1.3.11) 


@MulticastPort 


@Port 

(Clause C.1.3.11) 


@SourceAddress 


(©Source 
(C.1.3.11) 


DataType 


Payloadid 

(refer to table 1 in TS 102 034 [3] and to table 2 in TS 102 539 [13]) 
(Clause C.1.3.19) 


@Type 


Payloadldcaid 

There is a direct mapping between the DVB Payloadid values and this 
field 

(Clause C.1.3.19) 


Segment 


Payloadid. Segment 
(C.1.3.19) 

This parameter is optional for DVB Push mode 


@ID 


Payloadid. Seament@ld 


(Clause C.1.3.19) 


(©Version 


Payloadid. Seqment@Version 


(Clause C.1.3.19) 



L.1 .2 Mapping of OMA BCAST ESG delivery descriptors to XIVIL 
schema for service attachment 

This clause describes the mapping of OMA BCAST ESG delivery descriptors to the generic XML schema for service 
attachment defined in annex M and clause 5.2.2.3. The mandatory/optional nature of the fields can be derived from 
there. 



TISPAN Element Name 


Corresponding OMA BCAST ESG element in OMA-TS- 


(copied from 
clause 5.2.2.3) 


BCAST Service Guide-VI [6], clause 5.4 and 
TS 102 471 [4], clause 9.1 


SSF 




@ID 


TISPAN defined field 


(©Technology 


When an OMA BCAST SSF is advertised, this field must be 
"openmobilealliance.org beast" 


©Version 


TISPAN defined field 


Description 


TISPAN defined field 


ServiceProvider 




@DomainName 


ProviderURI 

(TS 102 471 [4], clause 9.1.1) 


@LogoURI 


ProviderLogo 
([7], clause 9.1.1) 


Name 


ProviderName 

(TS 102 471 [4], clause 9.1.1) 


Description 




Pull 




(©Location 


This URI encodes the location of the Service Guide Delivery Descriptors 
and/or the Service Guide Delivery Units 
([6], clause 5.4) 


DataType 


Specifies the type of Service Guide data fragment. 
([6], clause 5.4) 
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TISPAN Element Name 
(copied from 
clause 5.2.2.3) 


Corresponding OMA BCAST ESG element In OMA-TS- 
BCAST_Servlce_Guide-V1_0 [6], clause 5.4 and 
TS 102 471 [4], clause 9.1 


@Type 


Options are "sgdd", "sgdu" and "sgdd+sgdu". Tine value is used to 
populate the body of the HTTP request 
([6], clause 5.4.3.1) 


Segment 


Service Guide Delivery Descriptor or Service Guide fragment. 

([6], clause 5.4.1) 

This parameter is mandatory for OMABCAST Pull mode 


@ID 


Service Guide Delivery Descriptor or Service Guide fragment identifier. 
Can be mapped to "id", "fragmentID" or "fragmentTransportID". Format 
is anyURI 
([6], clause 5.4.1.1) 


@Version 


Version of the Service Guide Delivery Descriptor or Service Guide 
fragment identifier. Can be mapped to "version" or "fragmentVersion". 
Format is unsignedint 
([6], clauses 5.4. 1.3 and 5.4. 1.5.2) 


Push 




@IPVersion 


IPVersion6, format is bit string. This is a binary flag, which, if set to "1", 

indicates IPv6 usage 

(TS 102 471 [4], clause 9.1.2) 


@MulticastAcldress 


Specifies the IP address of the FLUTE session transporting the ESG 
(TS 102 471 [4], clause 9. 1.2) 


@MulticastPort 


Specifies the port number of the IP stream of the FLUTE session 

transporting the ESG 

(TS 102 471 [4], clause 9.1.2) 


@SourceAddress 


Specifies the source IP address of the FLUTE session transporting the 
ESG 

(TS 102 471 [4], clause 9. 1.2) 


DataType 


Specifies the type of Service Guide data fragment 
(TS 102 471 [4], clause 5.4) 


@Type 


Options are "application/vnd.oma.bcast.sgdd+xml" and 

"application/vnd.oma.bcast.sgdu" 

([6], clause 5.4.2) 


Segment 


Service Guide Delivery Descriptor or Service Guide fragment 
(TS 1 02 471 [4], clause 5.4. 1) 

This parameter is mandatory for OMABCAST Push mode 


@ID 


Service Guide Delivery Descriptor or Service Guide fragment identifier. 
Can be mapped to "id", "fragmentID" or "fragmentTransportID". Format 
is anyURI 
([6], clause 5.4.1.1) 


©Version 


Version of the Service Guide Delivery Descriptor or Service Guide 
fragment identifier. Can be mapped to "version" or "fragmentVersion". 
Format is unsignedint 
([6], clauses 5.4. 1.3 and 5.4. 1.5.2) 



L.1 .3 Mapping of service action data record discovery records to 
XIVIL schema for service attachment 

This clause describes the mapping of Service Action Data record to the generic XML schema for service attachment 
defined in annex M and clause 5.2.2.3. 



ETSI 



192 



ETSI TS 183 063 V3.5.1 (2011-02) 



TISPAN clement Name 
(copied from clause 5.2.2.3) 


Corresponding Service Action Data fieid 


boh 




@ID 


TISPAN defined field 


©Technology 


when a Service Action Data record is advertised, this field must be 
"tispan.org sad" 


©Version 


TISPAN defined field 


Description 


TISPAN defined field 


ServiceProvider 


Service Provider information 


@DomainName 


An internet DNS domain name registered by the Service Provider that 
uniquely identifies the Service Provider 


@LogoURI 


Pointer to a Service Provider logo for potential display 


Name 


Name of the Service Provider for display in one or more languages; one 
Service Provider name is allowed per language code, and at least one 
language shall be provided 


Description 


Description of the Service Provider for potential display in one or more 
languages; one description is allowed per language code 


Pull 




©Location 


Location of the Service Action data Record 


DataType 


Type of Service Action Data (BC bookmark, N-PVR, CoD) 


@Type 


0x00 defines All service action data 
0x01 defines BC service action data 

0x02 defines CoD service action data 
0x03 defines N-PVR service action data 


— 

Segment 


Not applicable 




Not applicable 


@Version 


Not applicable 


rusn 


inol appiicaoie 


@IPVersion 




@MulticastAddress 


M r uT 

Not applicable 


iu^iviuiiicasir on 


iNoi appiicaoie 


©SourceAddress 


Not applicable 


DataType 


Not applicable 


@Type 


Not applicable 


Segment 


Not applicable 


@ID 


Not applicable 


©Version 


Not applicable 



L.2 Mapping of BC service 

L.2.1 Mapping of BC service for DVB technology 



Table L.1 : Mapping of SIP parameters for BC service 



IPTV SiP parameters 


DVB 


Request-URI 


Not retrieved from SSF 
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Table L.2: Mapping of SDP parameters for BC service 



IPTV SDP parameters for each media stream 


Corresponding DVB SD&S element in TS 102 034 [3], clause 

5.2.6.2 tables 4, 5 and 8 

(TS 102 034 [3] XML Schema clause reference) 


BC content stream 


Connection Data 




c=<network type> <address type> <connection 

address> 




<network type> 


Not retrieved from SSF 


<address type> 


Not retrieved form SSF 


<connection address> 


IPMulticastAddress@Address 
(Clauses C.1 .3.1 and C.I .3.1 1 ) 






Media Announcements for content delivery 




m=<media> <port> <transport> <fmt list> 




<media> 


"video", not retrieved from SSF 


<port> 


IPMulticastAddress@Port 
(Clauses C. 1.3. 10 and C. 1.3.11) 


<transport> 


"RTP/AVP" if IPMulticastAddress@Streaming="rtp" or if 
IPMulticastAddress@Streaming is not present 
"UDP/H2221/MP2T" or "UDP/RAW/RAW" if 
IPMulticastAddress@Streaming="udp" 
(Clauses C. 1.3. 10 and C.I. 3.11) 


<fmt> 


"33", not retrieved from SSF 


Bandwidtti 

b=AS :<bandwidtli> 


MaxBitrate 
(Clause C.I. 3. 8) 


BCServiceld 


Textualldentifier@ServiceName 

":"Textuaildentifier@DomainName (Clause C. 1.3. 24) 
Note that the Textualldentifier@DomainName is an optional 
attribute; therefore if it's not present, the field is copied from the 
OfferlngBase@DomainName (Clause C.1 .3.1 4) 


BCPacl<ageld 


Package@ld (Clause C.1. 3.16) 


FEC Stream 




Note that the multicast address and source address of the FEC stream can be the same as the BC content stream 


Media Announcements for FEC delivery 


see note 


m=<media> <port> <transport> <fmt list> 




<media> 


"application", not retrieved from SSF 


<port> 


IPMulticastAddress.FECBaseLayer@Port 
(Clauses C. 1.3. 10 and C. 1.3.6) 


<transport> 


RTP/AVP 


<fmt> 


Dynamic payload type 


a=rtpmap:<fmt> <encoding_name/clock_rate> 


<encoding_name/clock_rate> referring to the DVB-IP AL-FEC 

Base layer and is equal to: 
"vnd.dvb.iptv.alfec-base/90000" 


Connection Data at media level 




c=<network type> <address type> <connection 
address> 




<network type> 


Not retrieved from SSF 


<address type> 


Not retrieved from SSF 


<connection address> 


IPMulticastAddress.FECBaseLayer@Address (Clauses C.1. 3.10 
and C.1. 3.6) 


NOTE: The FEC delivery can only be associated to a RTP delivered content. 
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Table L.3: Mapping of IGMP parameters for BC service 



IPTV IGIUIP parameters 


Corresponding DVB SD&S element in TS 102 034 [3], ciause 5.2.6.2, 

tables 4 and 5 
(TS 102 034 [3] XML Schema clause reference) 


BC content stream 


<Multicast Address> 


IPI\/lulticastAddress@Address 

(Clauses C. 1.3. 10 and C.I. 3.11) 


<Source Address> 


IPMulticastAddress@Source 
(Clauses C. 1.3. 10 and C. 1.3. 11) 


FEC Stream 

Note that the multicast address and source address of the FEC stream can be the same as the Live content 
stream 


<l\/lulticast Address> 


If the FEC multicast address is not the same as the live stream address: 

IPI\/lulticastAddress.FECBaseLayer@Address 

(Clauses C. 1.3. 10 and C. 1.3.6) 


<Source Address> 


If the source address is not the same as the live stream: 
IPMulticastAddress.FECBaseLayer@Source 
(Clauses C. 1.3. 10 and C. 1.3.6) 



L.2.2 Mapping of BC service for OIVIA BCAST technology 

Clause L.2.2 describes the mapping of OMA BCAST ESG delivery descriptors to the TISPAN XML schema for service 
attachment. This mapping procedure allows for retrieving OMA BCAST ESG fragments from an SSF. The various 
types of ESG fragments and the relation between them is described in clause 5.1.1 of 

OMA-TS-BCAST_ServiceGuide-Vl_0 [6]" and shown in figure 1 of that clause. An ESG has separate fragments to 
describe the service (e.g. TV channel) and to describe the access to that service. From a Service fragment (clause 5.1.2.1 
in 1 6 1) a unique identifier can be obtained to map to the BCServicelD. The Access fragment can either contain or refer 
to an Session Description, which can take the form of an SDP. Thus, from an OMA BCAST SSF a UE can obtain TV 
channel identification, description and access information, where the latter is in the form of an SDP. 



Table L.4: lUlapping of SIP parameters for BC service 



IPTV SIP parameters 


OMA BCAST 


Request-URI 


Not retrieved from SSF 



Table L.5: Mapping of SDP parameters for BC service 



IPTV SDP parameters for each 
media stream 


Corresponding OMA BCAST 

element in OMA-TS- 
BCAST_ServiceGuide-V1_0 [6] 


Connection Data 




c=<network type> <address type> 
<connection address> 




<network type> 


SDP 


oddress type> 


SDP 


<connection address> 


SDP 






Media Announcements for content 




delivery 

m=<media> <port> <transport> <fmt list> 




<media> 


SDP 


<port> 


SDP 


<transport> 


SDP 


<fmt list> 


SDP 


Bandwidth 


SDP 


b=AS:<bandwidth> 




BCServiceld 


globalServicelD 


BCPackageld 


globalPurchaseltemID 



ETSI 



1 95 ETSI TS 1 83 063 V3.5.1 (201 1 -02) 



Table L.6: Mapping of IGMP parameters for BC service 



IPTV IGMP parameters 


OiUIA BCAST 


<Multicast Adclress> 


SDR 


<Source Address> 


SDP 



L.2.2A Mapping of BC service for TV-Anytime Phase 2 technology 

Clause L.2.2A describes the mapping of TV-Anytime Phase 2 elements to the TISPAN XML schema for service 
attachment. This mapping procedure allows for using TV-Anytime Phase 2 information in TISPAJM IMS based IPTV 
procedures. 



Table L.7A: Mapping of SDP parameters for BC service 



IPTV SDP parameters for each 
media stream 


Corresponding TV-Anytime Phase 2 element in 
TS 102 822-3-1 [33], TS 102 822-4 [35], and TS 102 822-3-3[55] 


Connection Data 

c=<networl< type> <address type> 
<connection address> 




<networl< type> 


ContentReferencingTable @ Result@ LocationsResult@ Locator 


oddress type> 


ContentReferencingTable @ Result@ LocationsResult@ Locator 


<connection address> 


ContentReferencingTable @ Result@ LocationsResult@ Locator 






IVIedia Announcements for content 
delivery 

m=<media> <port> <transport> <fmt list> 




<media> 


Prog ramlnformationTable@Programlnformation@AV Attributes 


<port> 


ContentReferencingTable @ Result® LocationsResult@ Locator 


<transport> 


ContentReferencingTable @ Result@ LocationsResult@ Locator 


<fmt list> 


ProgramlnformationTable@Programlnformation@AV Attributes 


Bandwidtli 
b=AS:<bandwidth> 


ProgramlnformationTable@Programlnformation@AVAttributes@Bitrate 


BCProgramId 


ProgramlnformationTable@Programlnformation@programld 


BCServiceld 


ServicelnformationTable@Servicelnformation@serviceld 


BCPacl<ageld 


PackageTable@Package@crid 



Table L.7B: Mapping of IGMP parameters for BC service 



IPTV IGMP parameters 


TV-Anytime Phase 2 


<Multicast Address> 


SDP 


<Source Address> 


SDP 



L.2.3 Use of the TV URI in the mapping of BC service for DVB 
technology and OMA BCAST technology 

TS 184 009 [16] specifies the TV URI as globally unique identifier to identify broadcast television channels. The TV 
URI is used in the mapping of BC service for DVB technology and OMA BCAST technology as follows. 

L.2.3. 1 DVB technology 

If DVB technology (see clause L.2.1) is used, then the ServiceName attribute of the TextuaUdentifier should be 
populated with the TV URI identifying the television channel. 

L.2.3.2 OMA BCAST technology 

If OMA-BCAST technology is used (see clause L.2.2), then the globalServicelD should be populated with the TV URI 
identifying the television channel. 
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L.2.3.3 TV-Anytime Phase 2 technology 

If TV-Anytime Phase 2 technology is used (see clause L.2.2A), then the serviceld should be populated with the TV URI 
identifying the television channel. 



L.3 Mapping of CoD service 

L.3.1 Mapping of CoD service for DVB technology 



Table L.7C: Mapping of SIP parameters for CoD service - DVB technology 



IPTV SIP parameters 


DVB BCG 


Request-URI 


Locator defined in TS 102 822-4 [35], in sip-uri format 


NOTE: the user part of the Request-URI is a free string format corresponding to a unique content 
instance for one service provider, e.g. sip: cod_content1_hd@service_provider1 .com. 



Table L.8: Mapping of SDP parameters for CoD service - DVB technology 



IPTV SDP parameters 


DVB BCG 


Connection Data at session level 


Not retrieved from SSF 


c=<network type> <address type> <connection 
address> 




< network type> 


Not retrieved from SSF 


<address type> 


Not retrieved from SSF 


<connection address> 


Not retrieved from SSF 






Media Announcements for content delivery 




m=<media> <port> <transport> <fmt list> 




<media> 


"video" - Not retrieved from SSF 


<port> 


Client port- Not retrieved from SSF 


<transport> 


"RTP/AVP" or "UDP/H2221/MP2T" or 
"UDP/RAW/RAW depending on the transport 
layer used for the content, see clause 5.1 .4.1 


<fmt> 


"33" - Not retrieved from SSF 


Bandwidth 


BitRatetype as defined in TS 102 822-3-1 [33], 
clause 6.3.5 


Media Announcements for FEC delivery 


see note 


m=<media> <port> <transport> <fmt list> 




<media> 


"application", not retrieved from SSF 


<port> 


Client port, not retrieved from SSF 


<transport> 


RTP/AVP 


<fmt> 


Dynamic payload type 


a=rtpmap:<fmt><encoding_name/clock_rate> 


<encoding_name/clock_rate> referring to the DVB- 
IP AL-FEC Base layer and is equal to: 
"vnd.dvb.iptv.alfec-base/90000" 


Connection Data at media level 




c=<network type> <address type> <connection 

address> 




<network type> 


Not retrieved from SSF 


oddress type> 


Not retrieved form SSF 


<connection address> 


Not retrieved from SSF 


NOTE: The FEC delivery can only be associated to an RTP delivered content. 
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L.3.2 Mapping of CoD service for OIVIA BCAST technology 



Table L.9: Mapping of SIP Parameters for CoD Service 



IPTV SIP parameters 


OMA BCAST 


Request-URI 





Table L.10: Mapping of SDP Parameters for CoD Service 



IPTV SDP parameters 


OMA BCAST 


Connection Data at session level 

c=<network type> oddress type> <conneGtion address> 




<network type> 


N/A 

UE local data 


oddress type> 


N/A 

UE local data 


<connection address> 


N/A 

UE local data 


Media Announcements for content delivery 
m=<media> <port> <transport> <fmt list> 




<media> 


FFS 


<port> 


N/A 

UE local data 


<transport> 


FFS 


<fmt list> 





L.3.3 IVIapping of CoD service for TV-Anytime Piiase 2 
technology 



Table L.11 : Mapping of SIP Parameters for CoD Service 



IPTV SIP parameters 


TV-Anytlme Phase 2 


Request-URI 





Table L.12: Mapping of SDP Parameters for CoD Service 



IPTV SDP parameters 


Corresponding TV-Anytime Phase 2 element in 
TS 102 822-3-1 [33], TS 102 822-4 [35] 


Connection Data at session level 
c=<network type> <address type> <connection 
address> 




<network type> 


ContentReferencingTable @ Result@ LocationsResult@ 
Locator 


<address type> 


ContentReferencingTable @ Result@ LocationsResult@ 
Locator 


<connection address> 


ContentReferencingTable @ Result© LocationsResult@ 
Locator 


IVIedia Announcements for content delivery 
m=<media> <port> <transport> <fmt list> 




<media> 


ProgramlnformationTable@Programlnformation@AV Attributes 


<port> 


N/A 

UE local data 


<transport> 


ContentReferencingTable @ Result® LocationsResult@ 
Locator 


<fmt list> 


ProgramlnformationTable@Programlnformation@AV Attributes 
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L.4 Mapping of IPTV Content Marker retrieval records to 
XML Schema for Service Attachment 

This clause describes the mapping of IPTV Content Marker retrieval records to the generic XML Schema for service 
attachment defined in annex M and clause 5.2.2.3. 

This clause describes the mapping of IPTV Content Marker record to the generic XML schema for service attachment 
defined in annex M and clause 5.2.2.3. 



Table L.I 3 



TISPAN Element Name 
(copied from clause 5.2.2.3) 


Corresponding IPTV Content Marker field 


SSF 




@ID 


TISPAN defined field 


@Technology 


When IPTV Content Marker retrieval is advertised, this field must be 
"tispan.org iptvcontentmarker" 


©Version 


TISPAN defined field 


Description 


TISPAN defined field 


ServiceProvider 


Service Provider information 


@DomainName 


An internet DNS domain name registered by the Service Provider that 
uniquely identifies the Service Provider 


@LogoURI 


Pointer to a Service Provider logo for potential display 


Name 


Name of the Service Provider for display in one or more languages; one 
Service Provider name is allowed per language code, and at least one 
language shall be provided 


Description 


Description of the Service Provider for potential display in one or more 
languages; one description is allowed per language code 


Pull 




©Location 


Location of IPTV Content Marker retrieval 


DataType 


Type of IPTVContent Marker 


@Type 


Not applicable 


Segment 


Not applicable 


@ID 


Not applicable 


©Version 


Not applicable 


Push 


Not applicable 


@IPVersion 




@MulticastAddress 


Not applicable 


@MulticastPort 


Not applicable 


@SourceAddress 


Not applicable 


DataType 


Not applicable 


@Type 


Not applicable 


Segment 


Not applicable 


@ID 


Not applicable 


©Version 


Not applicable 



L.5 Mapping of Download service for DVB technology 



Table L.14: Mapping of SIP parameters for Download service - DVB technology 



IPTV SIP parameters 


DVB BCG 


Request-URI 


Locator defined in TS 1 02 034 [3] 


NOTE: the Request-URI is an HTTP URI as defined in TS 102 034 [3] clause 10.3.2.2, 

e.q. http://announcements.provider1 .orq:80/dvb/cds/session description?Seqment=aOff#?dvb-cds-session- 


id=102 
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Table L.15: Mapping of SDP parameters for Download service - DVB technology 



In 1 V ou" paraineisrs 


n\/R RPfi 


Connection Data at session level 


Not retrieved from SSF 


c=<neiworK iyp6> oaoress iype> <conneciion 

aU(jrcbb> 




<llclW(jri\ iypc> 


InUI FciricVcu iruiTi oor 


<duurcbb Lypc> 


INUL IclllcVcU IIUIII oor 


<connection adclress> 


Not retrieved from SSF 






— A * — i 1 j~T 

Media Announcements for content delivery 




m=<media> <port> <transport> <fmt list> 




<media> 


"application" - Not retrieved from SSF 


<port> 


y- Not reTrieveo Trorn bor 


<transport> 


lOr, Inot retneveo Trorn bbr 


<f mt> 


" int\/ httr\ " Mnt ratria\/aH frnm QQP 

ipiv luip - iNuL icLricVcu iroiii oor 


Bandwidth 


BitRatetype as defined in TS 102 822-3-1 [33], 
clause 6.3.5 


Connection Data at media level 




c=<network type> <address type> <connection 
address> 




<networl< type> 


Not retrieved from SSF 


<address type> 


Not retrieved form SSF 


<connection address> 


Not retrieved from SSF 
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Annex M (normative): 

XML Schema for Service Attachment Information 

This annex describes the XML schema for the service attachment information to be retiu'ned to UE by SDF. This XML 
schema is used when the service attachment information is transported via SIP Push mode and Pull mode as described 
in clauses 5.2.2.1 (Push mode) and 5.2.2.2 (Pull mode). 

<?xml version="l . 0" encoding= "UTF-8 " ? > 

<xs : schema xmlns :xs= "http : / /www. w3 . org/2 001/XMLSchema" element ForiTiDefault= "qualified" 
attributeFormDef ault= "unqualified" > 

<xs: element name="SSFList" type="tSSFList"> 
<xs :annotation> 

<xs : documentation>XML Body of the SDF SIP Notify Response</xs : documentation> 
</xs :annotation> 
</xs :element> 

<xs : complexType name= " tSSFList " > 
<xs : sequence> 

<xs:element name="SSF" type="tSSF" maxOccurs= "unbounded" /> 
<xs:element name= "Extension" type="tExtension" minOccurs="0"/> 

<xs : any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 

</xs : sequence> 

<xs : anyAttribute namespace="##other" processContents= " lax" /> 

</xs : complexType> 



<xs : complexType name="tSSF"> 

<xs : sequence> 

<xs: element name= "Description" type="tMultilingual" minOccurs= " " 
maxOccurs= "unbounded" /> 

<xs: element name= " ServiceProvider " type= " tSSFServiceProvider " minOccurs= " " / > 
<xs:element name="Pull" type= " tSSFPull " minOccurs= " " maxOccurs= "unbounded" /> 
<xs:element name="Push" type= " tSSFPush" minOccurs= " " maxOccurs= "unbounded" /> 
<xs:element name="Extension" type= " tExtension" minOccurs= " " /> 

<xs : any namespace="##other" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 

</xs : sequence> 

<xs : attribute name="ID" type= " tHexadecimall6bit " use= " required" /> 
<xs : attribute name="Technology" type= "xs : string" use="required"/> 
<xs : attribute name = "Version" type="tVersion"> 

<xs : annotation> 

<xs : documentation>The version number is incremented when one or more attributes of 
the SSF element have changed, so that the receiver knows whether it should update its data or 
not . </xs : document at ion> 

</xs : annotation> 
</xs : attribute> 

<xs :anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType> 



<xs : simpleType name="tVersion" > 

<xs : restriction base= "xs : integer" > 
<xs : minlnclusive value="0"/> 
<xs : maxinclusive value="255"/> 
</xs : restriction> 
</xs : simpleType> 



<xs : complexType name= " tSSFServiceProvider" > 
<xs : sequence> 

<xs:element name="Name" type="tiyiultilingual" maxOccurs= "unbounded" /> 
<xs: element name= "Description" type="tMultilingual" minOccurs= " " 
maxOccurs= " unbounded" /> 

<xs:element name= "Extension" type=" tExtension" minOccurs= " " /> 
</xs : sequence> 

<xs : attribute name= "DomainName" type="tDomain" use=" required" > 
<xs : annotation> 

<xs : documentation>It is recommended that the DomainName complies with the "preferred 
name syntax" of RFC1034 clause 3 . 5</xs : documentation> 
</xs :annotation> 
</xs :attribute> 

<xs ; attribute name= "LogoURI " type= "xs ; anyURI " use= "optional " /> 
<xs :anyAttribute namespace="##other" processContents= " lax" / > 
</xs : complexType> 
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<xs ; simpleType name= " tDomain" > 

<xs : restriction base="xs : string" > 

<xs:pattern value=" ( ( . | \n | \r) * ) ? ( \ . ( . | \n| \r) *) +"/> 

</xs : restriction> 
</xs : simpleType> 



<xs : complexType name= " tSSFPull " > 
<xs : complexContent> 

<xs lextension base="tDataTypeList"> 

<xs ; attribute name= "Location" type="xs :anyURI" use=" required" /> 
<xs :anyAttribute namespace="##other" processContents= " lax" > 
<xs :annotation> 

<xs : documentation>Extension attribute to define further 

data</xs :documentation> 

</xs : annotation> 
</xs :anyAttribute> 
</xs :extension> 
</xs : complexContent> 
</xs : complexType> 

<xs : complexType name= " tSSFPush" > 
<xs : complexContent> 

<xs lextension base="tDataTypeList"> 

<xs : attribute name= " IpVersion" type="tVersion" use= "optional " /> 
<xs lattribute name="MulticastAddress" type="xs : string" use="required"/> 
<xs :attribute name= "MulticastPort " type="xs :unsignedShort" use="required"/> 
<xs :attribute name="SourceAddress" type= "xs : string" use= "optional " /> 
<xs :anyAttribute namespace="##other" processContents= " lax" > 
<xs :annotation> 

<xs :documentation> Extension attribute to define further data 
</xs :documentation> 
</xs :annotation> 
</xs :anyAttribute> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 



<xs : complexType name= " tDataTypeList " > 

<xs : sequence maxOccurs= "unbounded" > 
<xs: element name="DataType"> 
<xs : complexType> 

<xs: sequence minOccurs= " " maxOccurs= "unbounded" > 
<xs: element name= " Segment " > 
<xs : annotation> 

<xs : documentation>Segments are used to logically separate Service 
Selection inf ormation</xs : documentation> 

</xs : annotation> 
<xs : complexType > 

<xs : attribute name="ID" type= " tHexadecimallSbit " use= " required" /> 
<xs : attribute name= "Version" type="tVersion" use= "optional " /> 

</xs : complexType> 
</xs : element> 
</xs : sequence> 

<xs : attribute name="Type" type="tHexadecimal8bit" use=" required" > 
<xs : annotation> 

<xs : documentation> Specify the type of Service Selection Information 

that is delivered by the SSF 

</xs : documentation> 

</xs : annotation> 
</xs : attribute> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : complexType> 

<xs :complexType name="tExtension"> 

<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tMultilingual " > 
<xs : simpleContent> 

<xs : extension base= "xs : string" > 

<xs : attribute name=" Language" type="tLanguage" use="required"/> 
</xs : extension> 
</xs : simpleContent> 
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</xs : complexType> 

<xs : simpleType name= " tLanguage" > 

<xs : restriction base="xs : string" > 
<xs ;annotation> 

<xs : documentation> 

<definition xml : lang="en">ISO 639-2 Language code</def inition> 
</xs ; documentation> 
</xs : annotation> 
<xs ;minLength value="3"/> 
<xs :maxLength value="3"/> 
</xs : restriction> 
</xs : simpleType> 



<xs : simpleType name= " tHexadecimalSbit " > 
<xs : restriction base="xs : string" > 

<xs:pattern value=" [0-9a-fA-F] {l,2}"/> 
</xs : restriction> 

</xs : simpleType> 

<xs : simpleType name= " tHexadecimall6bit " > 
<xs : restriction base="xs : string" > 

<xs:pattern value=" [0-9a-fA-F] {l,4}"/> 
</xs : restriction> 

</xs : simpleType> 



</xs : schema> 
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Annex N (): 
Void 



NOTE: The content in Annex N is modified and moved to new annex Z. 
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Annex O (normative): 

Procedure for definition of new SSF technologies 

New SSF technologies may be defined for support of the TISPAN IPTV services. Two technologies are defined so far 
in the present document, OMA BCAST and DVB-IPTV. This annex describes how new technologies (e.g. browser 
based technologies) can be defined by organizations wilUng to use the framework provided in the present document. 

The following procedure specifies how to define new technologies: 

1) Definition of a technology. The Technology attribute of the XML schema defined in annex M is a string. 

The format of the Technology attribute shall be: <organization_name>_<subtechnology> where: 

The organization_name shall be the ICANN registered domain name of the organization that defines its 
technology. 

The subtechnology name identifies the SSF technology defined by the organization. It shall be unique 
within the context of the organization. It consists of one or more characters. AUowed characters are 
alphanumeric (i.e. 'a'-'z', 'A'-'Z', '0'-'9') plus the hyphen character ('-'). 

2) Definition of the service attachment XML schema defined in annex M as applicable to the newly defined 
technology. The technology uses the XML structure to carry all relevant information, following the definition 
described in clause 5.2.2.3. For example, the DataType XML element is used to carry information which is 
meaningful only with regards to the technology. Example of completed XML schemas can be found in 
clause L.l. 

3) Definition of the service selection procedures associated with the newly specified technology, for the Pull 
mode and the Push mode, if used. Procedures defined within the present document may be reused. 

4) Mapping of the service selection information to the IPTV services defined in the present document. Below is 
the mapping that has to be completed (provided the IPTV service is defined with the technology). 

Mapping for BC Service (example is found in clause L.2). 

Mapping for CoD Service (example is found in clause L.3). 
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Annex P (normative): 
XML Schema for UE Profile 

This XML Schema defines the UE information that is specified by UE during service attachment and may be carried 
within body of the SIP SUBSCRIBE request. 

The format of the attributes UserEquipmentID and IPEncapsulation is outside of the scope of the present document. 

The usage and personalization of the service selection data based on the attributes UserEquipmentClass and 
IPEncapsulation is outside of the scope of the present document. 

<?xml version="l . 0" encoding^ "UTF- 8 " ? > 
<xs : schema 

targetNamespace= "urn : org : etsi : ngn : params : xml :ns : iptvueprof ile" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvueprof ile" 
xmlns :xs="http : //www. w3 . org/2 01/XMLSchema" 
xmlns : tva= "urn : tva : metadata : 2 05 " 

elementFormDef ault= "qualified" attributeFormDef ault= "unqualified" > 

<xs : import namespace= "urn : tva : metadata : 2 005 " 

schemaLocation="tva_metadata_3-l_vl31 .xsd"/ > 

<xs :annotation> 

<xs : documentation xml : lang="en"> 
Defines the capabilities of the UE that is currently associated with the user 

</xs ; documentation> 
</xs : annotation> 

<xs:element name= "UEInf ormation" type="tUEProf ile"/> 
<xs : complexType name= " tUEProf ile" > 
<xs : sequence> 

<xs:element name= "UserEquipmentID" type="tUEID"/> 

<xs : element name= "UserEquipmentClass " type="tUserEquipmentClass"/ > 

<xs:element name= "Resolution" type="tResolution" minOccurs="0"/> 

<xs:element name="SupportedEncodings" type="tSupportedEncodings" minOccurs= " " 

maxOccurs= "unbounded" / > 

<xs:element name= " IPEncapsulations " type="tIPEncapsulations" minOccurs="0" 

maxOccurs= "unbounded" /> 

<!-- extension mechanism --> 

<xs:element name="any" type="AnyType"></xs ;element> 
<xs:any namespace="##any" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name="AnyType"> 
<xs : sequence> 

<xs:any namespace="##any" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name="tUEID" final="list restriction" > 
<xs : annotation> 

<xs ; documentation> 

<label xml : lang= "en" >User Equipment ID</label> 

<definition xml : lang="en">Unique Identifier for the UE(eg; Could be MAC address 

of UE) </def inition> 

</xs : documentation> 
</xs : annotation> 

<xs : restriction base="xs : string" > 

<xs :minLength value="0"/> 

<xs :maxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="tUserEquipmentClass" final="list restriction" > 
<xs :annotation> 

<xs : documentation> 

<label xml : lang= "en" >User Equipment class</label> 

<definition xml : lang="en">Specif ies the type of UE </def inition> 
</xs : documentation> 
</xs : annotation> 
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<xs : restriction base="xs : string" > 

<xs : enumeration value="STB"> </xs : enumeration> 

<xs : enumeration value="PC"> </xs : enumeration> 

<xs : enumeration value= "Handset " > </xs ;enumeration> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name= " tResolution" > 

<xs : attribute name="HorizontalSize" tYpe= "xs : integer " > 
<xs ;annotation> 

<xs : documentation>horizontal size in pixels of the screen</xs :documentation> 
</xs :annotation> 
</xs :attribute> 

<xs : attribute name="VerticalSize" type="xs : integer" > 
<xs : annotation> 

<xs : documentation>vertical size in pixels of the screen</xs :documentation> 
</xs :annotation> 
</xs :attribute> 

<xs :attribute name="Rotate" type="xs :boolean"> 
<xs :annotation> 

<xs : documentation>set to TRUE if the screen can be rotated (horizontal becomes 
vertical) </xs ;documentation> 
</xs ; annotation> 
</xs :attribute> 
</xs : complexType> 

<xs : complexType name= " tSupportedEncodings " > 
<xs :annotation> 

<xs : documentation> 

<label xml : lang="en">encodings</label> 

<definition xml : lang="en">Specif ies the supported combinations of audio and video 
encodings {eg. iyiPEG2,H264 AC3 , AAC etc) </def inition> 
</xs : documentation> 
</xs :annotation> 
<xs : sequence> 

<xs:element name="AudioEncoding" type="tAudioEncoding" minOccurs= " " 
maxOccurs= "unbounded" /> 

<xs:element name= "VideoEncoding" type="tVideoEncoding" minOccurs= " " 
maxOccur s = " unbounded" / > 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tAudioEncoding" > 
<xs :annotation> 

<xs : documentation> 

<label xml : lang= "en" >Audio Encoding</label> 

<definition xml : lang= "en" >Specif ies supported audio encoding properties</def inition> 
</xs : documentation> 
</xs :annotation> 
<xs : sequence> 

<xs:element name= "Encoding" type= " tva : ControlledTermType" /> 
<!-- extension mechanism --> 

<xs: element name="any" type="AnyType"></xs :element> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tVideoEncoding" > 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >Video Encoding</label> 

<definition xml : lang="en"> Specifies supported video encoding properties 

</def inition> 

</xs : documentation> 
</xs : annotation> 
<xs : sequence > 

<xs:element name=" Encoding" type= "tva : ControlledTermType" /> 

<xs:element name="SupportedFrameRate" type= " tva : FrameRateType" minOccurs= " " 

maxOccurs= "unbounded" / > 

<!-- extension mechanism --> 

<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType > 



<xs : simpleType name= " tIPEncapsulations " > 
<xs : annotation> 

<xs :documentation> 

<label xml : lang= "en" >encapsulation</label> 
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<definition xml : lang="en">Specif ies the IP encapsulation that is supported on device 
("UDP/RTP" or "UDP/M2TS" or "UDP/RTP/M2TS" ) 
</def inition> 

</xs : documentation> 
</xs : annotation> 

<xs : restriction base="xs : string" > 

<xs : enumeration value= "UDP/RTP" > </xs :enumeration> 
<xs : enumeration value="UDP/M2TS"> </xs :enumeration> 
<xs : enumeration value="UDP/RTP/M2TS"> </xs ;enumeration> 
</xs : restriction> 
</xs : simpleType> 
</xs : schema> 

Example of XML document conforming to this structure. The SupportedEncoding field carries the list 
of the several coding format that the device can handle. The Name element is optional, it is 
presented herein for user readability. 

<?xml version="l . 0" encoding="UTF-8"?> 

<UEInf ormation xmlns= " ? " xmlns ;xsi= "http : //www. w3 . org/2 OOl/XMLSchema- instance" > 
<UserEquipment ID>STB -dcl4b2 < /UserEquipment ID> 
<UserEquipment Class >STB</UserEquipment Class > 

<Resolution Horizontal="720" Vertical="576" Rotate=" FALSE "/> 
<SupportedEncodings> 
<AudioEncoding> 

<Encoding href = "urn:mpeg :mpeg7 : cs : AudioCodingFormatCS : 2 001 : 3 " > 
<Name>MPEG-l Audio</Name> 

</Encoding> 
< / AudioEncoding > 
<AudioEncoding> 

<Encoding href = "urn ;mpeg : mpeg? : cs ; AudioCodingFormatCS :2001:5.4"> 
<Name>MPEG-4 Main Audio Prof ile</Name> 

</Encoding> 
< / AudioEncoding> 
<AudioEncoding> 

<Encoding href = "urn : mpeg :mpeg7 : cs ; AudioCodingFormatCS :2001:5.5"> 
<Name>MPEG-4 High Quality Audio Prof ile</Name> 

</Encoding> 
< / AudioEncoding> 
<AudioEncoding> 

<Encoding href = "urn: dvb : metadata : cs : AudioCodecCS : 2 007 : 1 " > 
<Name>MPEG-4 DVB Audio</Name> 

</Encoding> 
< /AudioEncoding> 
<VideoEncoding> 

<Encoding href = "urn : mpeg :mpeg7 : cs : VisualCodingFormatCS : 2 001 : 1 " > 
<Name>MPEG-l Video</Name> 

</Encoding> 
< /VideoEncoding> 
<VideoEncoding> 

<Encoding href = "urn : mpeg :mpeg7 : cs : VisualCodingFormatCS ;2001:2.2"> 

<Name>MPEG-2 Video Main Prof ile</Name> 
</Encoding> 
< /VideoEncoding> 
<VideoEncoding> 

<Encoding href = "urn : dvb : metadata : cs : VideoCodecCS :2007:1.1"> 

<Name>H264 Baseline Prof ile</Name> 
</Encoding> 

<SupportedFrameRate>3 0</SupportedFrameRate> 
< /VideoEncoding> 
<VideoEncoding> 

<Encoding href =" urn : dvb : metadata : cs : VideoCodecCS :2007:1.2"> 

<Name>H264 Main Prof ile</Name> 
</Encoding> 

<SupportedFrameRate>30</SupportedFrameRate> 
< Support edFrameRate>24</SupportedFrameRate> 
< /VideoEncoding> 
</SupportedEncodings> 
<IPEncapsulation>M2TS/UDP</IPEncapsulation> 
<IPEncapsulations>M2TS/RTP</IPEncapsulations> 
</UEInf ormation> 
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Annex Q (informative): 

Combination of SIP and RTSP protocols for content on 
demand 

The SIP procedures described in clause 5 influence which of the two RTSP methods described in clause 7 to be used. 
Figures Q.l and Q.2 specify the decision logic of the UE and the MCF respectively. 



Q.1 User Equipment (UE) side RTSP method decision 
logic 



Figure Q.l shows the UE-side RTSP method decision logic. 
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Figure Q.1 : UE-side RTSP method decision logic 
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Q.2 Media Control Function (MCF) side RTSP method 
decision logic 

Figure Q.2 shows the MCF-side RTSP method decision logic. 
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Figure Q.2: MCF-side RTSP metliod decision logic 
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Annex R (informative): 
Initial Filter Criteria 

Beyond the method name, (SUBCRIBE, INVITE, etc.), the following elements may be used a service trigger point to 
build initial filter criteria enabling Application Servers to be involved in the processing of IPTV procedures: 

The event name of a SUB SCRIBE request. 

The contents of the Accept header in a SUBSCRIBE request (e.g. MIME types). 

The contents of the P-Preferred-Service header or the Accept-Contact header (i.e. ICSI). 

The Request-URI, in which case the content tag will typically contain an Extended Regular Expressions (ERE) 
as defined in clause 9 in IEEE 1003. 1-2004 [i.5] such that any Request-URI that includes a particular pattern 
(e.g. a domain name) matches the criteria. 

The actual list of criteria depends on whether the public user identity is dedicated to the IPTV service or not. 

The following example illustrates the case of an IPC used to trigger an application server that provides the SDF function 
only. 

<InitialFilterCriteria> 

<Priority>0</Priority> 
<Tr igger Point > 

<ConditionTypeCNF>0</ConditionTypeCNF> 

<SPT> 

<ConditionNegated>0</ConditionNegated> 

<Group>0</Group> 

<Method>INVITE</Method> 
</SPT> 
<SPT> 

< Condi tionNegated>0< /Condi tionNegated> 
< Group > < /Group > 

<RequestURI>@iptvdiscovery .homedomain. com$</RequestURI> 

</SPT> 
</Tr igger Point > 
<ApplicationServer> 

<ServerName>sip : SDF-ASl@homedomain . com</ServerName> 

<Def aultHandling>0</Def aultHandling> 
</ApplicationServer> 
</lnitialFilterCriteria> 
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Annex S (normative): 

XML Schema for IPTV Notification 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 

<xs : schema targetNamespace= "urn : org : etsi : ngn : params : xml : ns : iptvnotif ication" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvnotif ication" 
xmlns : xs = "http : / /www . w3 . org/2 01/XMLSchema" 

xmlns : nt= "urn : org : etsi : ngn : params : xml : ns : iptvnotif ication" attributeFormDef ault= "unqualified" > 

<xs:element name= " IPTVNotif ication" type= " tIPTVNotif ication" /> 
<xs : complexType name= "tIPTVNotif ication" > 
<xs : sequence> 

<xs:element name="Notif icationReason" type="tNotif icationReason" minOccurs="l" 

maxOccurs= " 1 " /> 

<xs:element name= "Notif icationSender " type= "xs : string" minOccurs= " " /> 
<xs:element name="ContentIdentif ier" type= "xs : anyURI " minOccurs= " " /> 
<xs: element name= "Notif icationReceiver" type= "xs : string" minOccurs= " " /> 
<xs : choice> 

<xs: element name="MediaPathNotif icationinf o" type= " tMediaPathNotif icationinf o" /> 
<xs: element name="ContentInsertionInf o" type="tContentInsertionInfo" /> 
<xs:element name= " IncomingCallInf o" type="tIncomingCallInfo" /> 
<xs: element name="CPVRRecordInfo" type="tCPVRRecordInfo" /> 

<xs: element name="ContentRecommendationInfo" type="tContentRecommendationInfo" /> 
<xs:element name="Extension" type= " tExtension" minOccurs= " " maxOccurs="unbounded"/> 
</xs : choice> 
</xs : sequence> 
</xs : complexType> 



<xs : simpleType name= " tNotif icationReason" > 
<xs : restriction base= "xs : string" > 

<xs : enumeration value= " Contentlnsertion" /> 
<xs : enumeration value= " InstantMessage" /> 
<xs : enumeration value= " IncomingCall " /> 
<xs : enumeration value= " CPVRRecord" /> 
<xs : enumeration value="ContentRecommendation" /> 
</xs : restriction> 
</xs : simpleType> 



<xs : complexType name= "tMediaPathNotif icationinf o" > 

<xs : sequence> 

<xs: element name= "MulticastAddress " type= "xs : string" minOccurs= " 1 " /> 

<xs : choice> 

<xs:element name= " InstantMessageInf o" type= "xs : string" minOccurs= " " /> 
<xs:element name="Extension" type="tExtension" minOccurs="0" /> 
</xs : choice> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= "t Content Insert ionlnfo" > 
<xs : sequence> 

<xs: element name= " Sessionid" type= "xs : string " minOccurs= " 1 " /> 

<xs:element name="ContentInsertionReason" type= " tContentlnsertionReason" minOccurs= 

<xs:element name="ContentInsertionTime" minOccurs= " " > 
<xs : complexType> 
<xs : sequence> 

<xs:element name= " ContentlnsertionStartTime " type= "xs : dateTime" /> 
<xs: element name="ContentInsertionDuration" type= "xs : duration" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
<xs : choice> 

<xs: element name= "MulticastContent " type= "xs : anyURI " /> 
<xs: element name= "UnicastContent " type= "xs : anyURI " /> 
</xs : choice> 
</xs : sequence> 
</xs : complexType> 



<xs : simpleType name= " tContentlnsertionReason" > 
<xs : restriction base= "xs : string" > 

<xs : enumeration value= "Advertising" /> 
<xs : enumeration value="PausedContent" /> 
<xs : enumeration value="Generic" /> 
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<xs : enumeration value= "Extension" /> 
</xs : restriction> 
</xs : simpleType> 



<xs : complexType name= " tIncomingCallInf o" > 
<xs : sequence> 

<xs:element name=" Caller ID" type= "xs : anyURI " minOccurs= " 1 " /> 
</xs : sequence> 
</xs : complexType> 

<xs : complexType name= " tCPVRRecordInf o" > 
<xs : sequence> 

<xs:element name="CPVRContentID" type= "xs : anyURI " minOccurs= " " /> 
<xs: element name= "BCServiceld" type= "xs : anyURI " minOccurs= " 1 " /> 
<xs:element name="RecordEndDate" type="xs idateTime" minOccurs="l" /> 
< /xs : s equence > 
</xs : complexType> 

<xs : complexType name="tContentRecommendationInfo" > 
<xs : sequence> 

<xs;element name=" Content Ident if er" minOccurs="l" maxOccurs= "unbounded" > 
<xs : complexType> 

<xs : simpleContent> 

<xs : extension base= "xs : anyURI " > 

<xs :attribute name="ServiceType" type= "xs : string" use= "optional " /> 
</xs : extension> 
</xs : simpleContent> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : complexType> 



<xs : complexType name= " tExtension" > 
<xs :annotation> 

<xs : documentation> 

This element is reserved for further extensions 
</xs :documentation> 
</xs :annotation> 
<xs : sequence > 

<xs:any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType> 

</xs : schema> 
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Annex T (normative): 

XML Schema for Restricted Trick Play 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<xs : schema 

xmlns :xs="http : //www. w3 . org/2 1/XMLSchema" 

xmlns : uep= "urn : org : etsi : ngn : params :xml :ns : iptvrestrictedtrickplay" 
element FormDefault= "qualified" 
attributeFormDef ault= "unqualified" > 

<xs : element name= " IPTVRestrictedTrickPlay" > 

<xs : complexType> 
<xs : sequence> 

<xs: element name="RestrictedTrcikPlayPolicy" maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs : element name="RestrictedTrickPlayPolicy"> 

<xs : complexType> 
<xs : sequence> 

<xs:element name="ContentID" type= "xs : string" minOccurs= " " / > 
<xs:element name= " StartTime " type= "xs : string" minOccurs= " " /> 
<xs:element name= " EndTime " type="xs : string" minOccurs= " " /> 

<xs:element name="RTSPOperation" type= " tRTSPOperation" maxOccurs= "unbounded" /> 
<xs:element name="Extension" type= " tExtension" minOccurs= " " /> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs : complexType name= "tExtension" > 

<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name= " tRTSPOperation" > 

<xs : restriction base= "xs : unsignedByte" > 
<xs : minlnclusive value="0"/> 
<xs : maxinclusive value="l"/> 
<xs : enumeration value="0"> 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >FastForward</label> 

<definition xml : lang= "en" >Reqeust to fast f orward</def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 
<xs : enumeration value="l"> 
<xs : annotation> 

<xs : documentation> 

< label xml : lang= "en" >Pause</ label > 

<definition xml : lang= "en" >Request to pause</def inition> 
< /xs : documentat ion> 
</xs :annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType> 

</xs : schema> 



ETSI 



214 



ETSI TS 183 063 V3.5.1 (2011-02) 



Annex U (normative): 

XML Schema for PCh Conflict Option & Choice data 

<?xml version="l . 0" encoding^ "UTF- 8 " ? > 

<xs : schema t argetName space = "urn : org : etsi : ngn : params :xml :ns : iptvpchdata" 
xmlns= "urn : org : etsi : ngn : params : xml : ns : iptvpchdata" 

xmlns : ns= "urn : org : etsi : ngn : params : xml : ns : iptvpchdata" xmlns : xs= "http : //www. w3 . org/2 OOl/XMLSchema" 
elementFormDefault= "qualified" attributeFormDef ault= "unqualified" > 

<xs : element name= " PChConf lictOptionData" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name="Conf lictOption" type="tPChConf lictOption" minOccurs= " 1 " 

maxOccurs= "unbounded" / > 

</xs : sequence> 

</xs : complexType> 
</xs :element> 

<xs:element name="PChConf lictChoiceData" type="tPChConf lictOption" /> 

<xs : simpleType name= " tPChConf lictOption" > 
<xs : restriction base= "xs : string" > 

<xs : enumeration value="PlayAndRecord"> 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= " en" > Keeps the on-going session alive and initiates 
another task for recording the upcoming BC content </def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 

<xs : enumeration value= "PlayAndDelay" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= " en" > Keeps the on-going session alive and delay the play 
of the upcoming CoD content by modifying the PCh profile info </def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 

<xs : enumeration value= "SwitchAndMark" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= " en" > Teardown the on-going session, mark the current CoD 
content play information, and switch to the next PCh item as indicated </def inition> 
</xs : documentation> 
</xs : annotation> 
</xs : enumeration> 

<xs : enumeration value= "SwitchAndRecord" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= "en" > Teardown the on-going session, record the current BC 
content, and switch to the next PCh item as indicated </def inition> 
</xs :documentation> 
</xs :annotation> 
</xs ; enumeration> 

<xs lenumeration value="PlayAndSwitch"> 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang= "en" > Keep the on-going session alive till its end and 
switch to the next PCh item as indicated </def inition> 
</xs :documentation> 
</xs :annotation> 
</xs : enumeration> 
</xs : restriction> 
</xs : simpleType > 
</xs : schema> 
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Annex V (normative): 

XML Schema for IPTV Content Marker 

<?xml version="l . 0" encoding="UTF-8"?> 

<xs : schema targetNamespace= "urn : org : etsi :ngn :params :xml :ns : iptvinf ormation" 
xmlns :xs="http: //www.w3 .org/2001/XMLSchema" 

xmlns= "urn : org : etsi :ngn:params :xml :ns : iptvinf ormation" elementFormDefault= "qualified" 
attributeFormDef ault= "unqualified" > 

<xs : element name= " IPTVContentMarkerRequest " > 
<xs : complexType> 
<xs : sequence> 

<xs:element name= " IPTVInf ormationDataCommand" type="tIPTVInformationDataCommand" /> 
<xs lelement name="IPTVContentMarker" type="tIPTVContentMarker" 
maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType> 
</xs :element> 

<xs : simpleType name="tIPTVInformationDataCommand"> 
<xs : restriction base="xs : string" > 

<xs : enumeration value= "Update" /> 
<xs : enumeration value= "Retrieval " /> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name= " tIPTVContentMarker " > 
<xs : sequence> 



<xs ; 


: element 


name= 


"IPTVContentMarkerlD" type="xs : string" /> 


<xs ; 


: element 


name= 


"OwnerUserlD" type= "xs : string" /> 


<xs ; 


: element 


name= 


"ForbiddenViewUser" type="xs : string" minOccurs= " " 


maxOccurs= "unbounded" /> 




<xs ; 


: element 


name= 


"IPTVServiceType" type= "xs : string" /> 


<xs ; 


: element 


name= 


" StartTimeOf IPTVContentMarker " type= "xs : dateTime " minOccurs= " " / > 


<xs ; 


: element 


name= 


" EndTimeOf I PTVContentMarker " type= "xs : dateTime " minOccurs= " " / > 


<xs ; 


: element 


name= 


"Tag" type= "xs : string" minOccurs= " " /> 


<xs ; 


: element 


name= 


"Rank" type= "xs : string" minOccurs= " " /> 


<xs : 


: element 


name= 


"UserComment " type="xs : string" /> 


<xs : 


: element 


name= 


"GenerationTime" type="tExtension" minOccurs= " " /> 


<XS : 


: element 


name= 


"ExpiryTime" type="tExpiryTime" minOccurs="0"/> 


<XS : 


: element 


name= 


"RetrievalCount " type="xs :nonNegativeInteger" minOccurs="0"/ > 


<XS 


: element 


name= 


"RetrievalTime" type="xs : dateTime" minOccurs="0" 


maxOccurs= " unbounded" /> 







</xs : sequence> 
</xs : complexType> 



<xs : complexType name= " tExtension" > 

<xs : sequence> 

<xs : any processContents= " lax" minOccurs= " " maxOccurs= "unbounded" /> 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name= " tExpiryTime " > 

<xs:union memberTypes= " tExpiryTimeException xs : dateTime" / > 
</xs : simpleType> 

<xs : simpleType name= " tExpiryTimeException" > 
<xs : restriction base= "xs : integer" > 

<xs: pattern value= " ( - 1 | ) " /> 
</xs : restriction> 
</xs : simpleType> 
</xs : schema> 
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Annex W (normative): 
Inter-destination media synchronization 

W.1 RTCP XR Block Type for inter-destination media 
synchronization 

Figure W.l describes the RTCP XR Block Type for reporting inter-destination media synchronization information on 
an RTP media stream. Its definition is based on [45]. The RTCP XR is used to report information on receipt times and 
presentation times of RTP packets to e.g. a Sender [44], a Feedback Target [43] or a Third Party Monitor [44]. The 
RTCP XR is also used to indicate synchronization settings instructions to a receiver of the RTP media stream. 

Figure W.l : RTCP XR Block Type for inter-destination media synclironization 

The first 64 bits form the header of the RTCP XR, as defined in [45]. The SSRC of packet sender identifies the sender 
of the specific RTCP packet. 

• Block Type (BT): 8 bits. It identifies the block format. Its value shall be set to 12. 
NOTE: The value BT=12 has been registered by lANA [i.l2]. 

• Synchronization Packet Sender Type (SPST): 4 bits. This field indentifies the role of the packet sender for 
this specific eXtended Report. It can have the following values. 



Table W.1 : Synchronization Packet Sender Types (SPST) 



SPST 

value 


Role of packet 
sender 


Details 





Reserved 


For future use. 


1 


SC, see clause 5.7. 


The packet sender uses this XR to report synchronization status information. 
Timestamps relate to the SC input. 


2 


MSAS, see clause 5.8. 


The packet sender uses this XR to report synchronization settings instructions. 
Timestamps relate to the input of a virtual SC, which acts as reference to which the 
SCs connected to this MSAS are synchronized. 


3 


SC input 


The packet sender uses this XR to report synchronization correlation information 
related to the incoming media stream of SC. Timestamps relate to the SC input. 


4 


SCoutput 


The packet sender uses this XR to report synchronization correlation information 

related to the outgoing media stream of SC. Timestamps relate to the SC input, 
(see note) 


5 to 15 


Reserved 


For future use. 


NOTE: Following the RTP/RTCP specification [44], RTP timestamps relate to the arrival time of the first octet of an 
RTP packet. In case of SPST=4 (SC output), there is not such an arrival time as the media stream is re- 
originated at the SC. In this case, the timestamp would relate to the arrival time of the equivalent octet 
(representing e.g. the same video pixel or audio sample) of the incoming media steam. 



• Reserved bits (Resrv): 3 bits. These bits are reserved for future use and shall be set to 0. 

• Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the Packet Presented NTP timestamp 
contains a value, if it is empty. If this flag is set to zero, then the Packet Presented NTP timestamp shall not 
be inspected. 

• Block Length: 16 bits. This shall be set to 7, as this RTCP Block Type has a fixed length. 

• Payload Type (PT): 7 bits. This field identifies the format of the media payload, according to [57]. The media 
payload is associated with an RTP timestamp clock rate. This clock rate provides the time base for the RTP 
timestamp counter. 

• Reserved bits (Resrv): 25 bits. These bits are reserved for future use and shall be set to 0. 
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• Media Stream Correlation Identifier: 32 bits. This identifier is used to correlate synchronized media 
streams. The value (all bits are set "0") indicates that this field is empty. The value 2^^32-1 (all bits are set 
"1") is reserved for future use. If the RTCP Packet Sender is an SC or an MSAS (SPST=1 or SPST=2), then 

the Media Stream Correlation Identifier maps on the SyncGroupId. If the RTCP Packet Sender is an SC 
(SPST=3 or SPST=4), related incoming and outgoing media streams have the same Media Stream Correlation 
Identifier. 

• SSRC: 32 bits. The SSRC of the media source shall be set to the value of the SSRC identifier carried in the 
RTP header [44] of the RTP packet to which the XR relates. 

• Packet Received NTP timestamp: 64 bits. This NTP timestamp [56] is the arrival wallclock time of the first 
octet of the RTP packet to which the XR relates. For SPST=2 it relates to a virtual SC to which the other SCs 
in the synchronization group may synchronize. For SPST=4 the SC should calculate backwards when the 
content (video frame, audio sample) associated with the first octet of the RTP packet arrived. As specified in 
Clause 11.3.2, SCs shall be NTP synchronized. 

• Packet Received RTP timestamp: 32 bits. This timestamp has the value of the RTP time stamp carried in the 

RTP header [44] of the RTP packet to which the XR relates. 

• Packet Presented NTP timestamp: 32 bits. This timestamp reflects the NTP time when the data contained in 
the first octet of the associated RTP packet is presented to the user. It consists of the least significant 16 bits of 

the NTP seconds part and the most significant 16 bits of the NTP fractional second part. If this field is empty, 
then it shall be set to and the Packet Presented NTP timestamp flag (P) shall be set to 0. It shall be empty for 
SPST=3 and SPST=4. 



W.2 SDP parameter for inter-destination media 
synchronization 

The SDP parameter sync-group is used to signal the use of the RTCP XR block for inter-destination media 
synchronization specified in clause W.l. This SDP parameter extends rtcp-xr-attrib as follows, using Augmented 
Backus-Naur Form [61]. 

rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)J CRLF; Original definition from RFC 3611 [45], 
clause 5.1 

xr-format =/ grp-sync; Extending xr-format for inter-destination media synchronization 
grp-sync = "grp-sync" [",sync-group=" SyncGroupId] 
SyncGroupId = 1*DIGIT; Numerical value from fill 4294967295 
DIGIT = %x30-39 

SyncGroupId is a 32-bit unsigned integer in network byte order and represented in decimal. SyncGroupId identifies a 
group of SCs for inter-destination media synchronization. It maps on the Media Stream Correlation Identifier of Annex 
W.l for SPST=1 and SPST=2. The value SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295 
(2^^32-1) is reserved for future use. 

The following is an example of the SDP attribute for inter-destination media synchronization. 

• a=rtcp-xr:grp-sync,sync-group=42 
NOTE: The parameter "grp-sync" for the SDP attribute "a=rtcp-xr" has been registered by lANA [i.l3]. 



W.3 Introduction to inter-destination media 
synchronization (informative) 

This clause provides an informal introduction to inter-destination media synchronization to aid the understanding of 
annex W. Detailed procedures are provided in the main body of this specification. 
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The purpose of inter-destination media synchronization is achieving that content is played out synchronously on 
terminals of two or more users watching the same content, compensating for delay difference caused by transport, 
coding and other. 

The following functional elements are involved in inter-destination media synchronization. 

• SC: Synchronization Client: 

Mapping 1 : SC in User Equipment (UE), supports both SIP and RTCP signalling 
Mapping 2: SC in Transport Processing Functions, supports only RTCP signalling 

• MS AS: Media Synchronization Application Server: 

Session-oriented part for SIP signalling, typically co-located with the Sevice Control Function (SCF) 

Media-oriented part for RTCP signalling, typically separate from the session-oriented part and closer to 
the media streams 

• SC: Synchronization Client prime: 

Option for functional entities that modify and/or re-originate media streams, Uke transcoders 

If SIP is supported (mapping 1) then the SC may initiate a synchronization session by including the "a=rtcp-xr:grp- 
sync,sync-group=<SyncGroupId>" SDP attribute in the SIP message. The SyncGroupId identifies the group of SCs 
involved in inter-destination media synchronization, which is similar to the Conferenceld in a conference call. 

The session-oriented part of the MS AS responds to the SC, providing the IP address and port number of the media- 
oriented part of the MSAS and providing or confirming the SyncGroupId. 

There are several variations to the SIP signalling, depending whether inter-destination media synchronization is initiated 
together with session initiation or later in the session, and on the SIP/RTSP signalling method used. 

RTCP signalling SC, SC and MSAS uses the RTCP XR specified in clause W.l. The Synchronization Packet Sender 
Type (SPST) indentifies the role of the packet sender for this specific extended Report. 

• From SC to MSAS: synchronization status information, such as arrival time information (SPST=1) 

• From MSAS to SC: delay infromation in the form of synchronization settings instructions (SPST=2) 

• From SC to MSAS: synchronization correlation information: 

related to the SC input (SPST=3) 

related to an SC output (SPST=4) 

RTCP signalling is used between SC and MSAS, and from SC to MSAS, using the RTCP XR specified in clause W.l. 
The Synchronization Packet Sender Type (SPST) indentifies the role of the packet sender for this specific eXtended 
Report. 

The Media Stream Correlation Identifier identifier is used to correlate synchronized media streams. For SC it 
corresponds to the SyncGroupId. For SC is it used to correlate the input and output(s) for a specific media stream. 

Together, arrival time infotmation such as the Packet Received NTP timestamp. Packet Received RTP timestamp and 
the Packet Presented NTP timestamp indicate at what wall-clock time an RTP packet passed or should pass a specific 
point in an SC or SC. 
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Annex X (normative): 

XML Schema for Content Switch 

<?xml version="l . 0" encoding= "UTF- 8 " ? > 
<xs : schema 

xmlns :xs="http : //www. w3 . org/2 1/XMLSchema" 

xmlns : uep= "urn : org : etsi : ngn : params :xml :ns : iptvcontent switch" 
element FormDefault= "qualified" 
attributeFormDef ault= "unqualified" > 

<xs : element name= " IPTVContentSwitch" > 

<xs : complexType> 
<xs : sequence> 

<xs: element name= " SwitchedContentltem" type= " tSwitchedContentltem" maxOccurs= "unbounded" 

/> 

</xs : sequence> 

<xs : attribute name=" content -id" type= "xs : string" use=" required" /> 
</xs : complexType> 
</xs ;element> 

<xs : complexType name="tSwitchedContentItem"> 

<xs : sequence> 

<xs:element name="ContentItemID" type="xs : string" minOccurs= " 1 " / > 
<xs:element name="ContentItemName" type= "xs : string" minOccurs= " 1 " /> 
</xs : sequence> 
</xs : complexType> 

</xs : schema> 
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Annex Y (normative): 

Support for an Application profile for SIP User Agents 

This annex defines the normative text for a new application profile for a SIP User agent in addition to the 3 existing 
profiles currently defined in the SIP Config framework. 



Y.1 Introduction 

SIP User Agents require profile data to function properly. A mechanism to obtain profile data is specified by the 
Framework for SIP User Agent Profile Dehvery I-D ietf-sipping-config-framework [63]. The framework separates 
profile data into three categories, termed profile types, local-network, device and user. Each profile type deals with a 
specific data set, e.g. the device profile type is used to obtain device-specific configuration. The framework also allows 
for future extensions to support additional profile types. The present document specifies one such extension to support 
an additional profile type, appUcation. This can be used by user agents for requesting profile data for one or more 
appUcations that they support. 



Y.2 Motivation 

The motivation for an independent application profile type can be demonstrated using the scenario described in 
figure Y.l. The scenario considers a device (not shown) that supports three appUcations (X, Y, Z). It also considers two 
users (A, B). Applications X and Y are user- specific, i.e. restricted to known end-users, where as Application Z can be 
used by any user (e.g. Weather Information). 



App X I I App Y I I App Z 



<any user> 



UserAI |UserB 



Figure Y.l : Motivation for application profile type 

Each application needs specific profile data to function. For instance, an appUcation such as Video on Demand (VoD) 
would require VoD server information, codecs for rendering, minimum bandwidth requirements etc. It may also have 
requirements specific to users, such as rating and cost restrictions (parental controls). Further, the presence of an 
appUcation does not always mean that it is enabled. For example, a Service Provider may disable VoD for certain 
subscription levels. 

Profile data related to such applications, especially those that are unrelated to specific users, would need to be retrieved 
for successful operation. This profile data may be retrieved during device boot-up if it is configured to do so, e.g. via the 
device profile. The profile data can also be retrieved dynamically, e.g. when the application is enabled. Such profile 
data does not quaUfy under any existing profile types specified by the SIP UA configuration framework, viz., 
local-network, device and user. The only exception is application profile data that is specific to users, which can be 
provided via the user profile type. Thus the need for an additional profile type specific to appUcations. 
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Y.3 Overview 



Y.3.1 Profile Type Definition 

The present document specifies a new profile type for use with the SIP UA configuration framework. The name of the 
profile type is 'application'. The present document also defines an additional event header parameter for use with the 
application profile type. This parameter is termed "appids". 

Y.3.2 Parameter 'appids' 

The "appids" parameter describes the application profiles being requested. Its value is an identifier for the appUcation, 
or a comma-separated list of such identifiers. Each application identifier is a unique value defined by the application 
specification, along with the profile content, and is in the form of a URI (RFC 4395 [66]), preferably a URN (RFC 3406 
[67]). This parameter value SHOULD be provided in the SUBSCRIBE request for the 'application' profile-type only, 
along with the other three parameters (vendor, model and version) specified in I-D. ietf-sipping-config-framework [63]. 
This parameter is useful to the PDS to affect the profile provided. Behavior when the "appids" parameter is omitted is 
currently undefined and treated as an error. Future standards action may specify this behavior. 

In the following ABNF defining the syntax, EQUAL and DQUOTE are defined in RFC 3261 [62]: 

appids = "appids=" list-of -app-ids 

list-of-app-ids = DQUOTE app-id *("," app-id) DQUOTE 
app-id = 1* (subset -print -chars) 

subset-print-chars= %x21 /%x23-25 / %x27-29 / %x2D-3C / %x3E-7E 

;A11 printable characters except ", =, &, *, + 
/comma or white-space characters. 

The "appids" parameter appears in the Event header of the NOTIFY request to specify the actual application the 
NOTIFY belongs to. In the initial NOTIFY following a SUBSCRIBE, the appids parameter SHOULD list all 
appUcations obtained in the subscription, which may be a subset of the applications listed in the SUBSCRIBE. The only 
case in which the "appids" parameter MAY be omitted from the initial NOTIFY is when only one application was listed 
in the SUBSCRIBE. If the SUBSCRIBE included an "appids" parameter, the "appids" parameter of the initial NOTIFY 
MUST NOT Ust applications not present in the SUBSCRIBE. If the parameter contains a list of applications, the order 
in the appids parameter MUST be the same as followed in the body (see below). Subsequent NOTIFY requests on a 
single application subscription MAY omit the "appids", since the application context is impUed by the subscription 
dialog. 

Y.3.3 Summary of Event Header 

The following are example Event headers which may occur in SUBSCRIBE requests. The examples are not intended to 
show complete SUBSCRIBE requests. 

Event : ua-prof ile;prof ile-type=application; 

vendor= "vendor . example . com" ;model= "ZlOO " ; version= "1.2.3" 

Event : ua-prof ile;profile-type=application; 

vendor= "vendor . example . com" ;model= "ZlOO " ; version= "1.2.3"; 
appids="myapplication" 

Event : ua-prof ile;profile-type=application; 

vendor= "vendor . example . com" ;model= "ZlOO " ; version= "1.2.3"; 
appids="myapplicationl ,myapplication2 ,myapplication3 " 

The following are example Event headers which may occur in NOTIFY requests. These example headers are not 
intended to be complete NOTIFY requests. 

Event : ua-prof ile;profile-type=application 

Event : ua-prof lie; prof lie- type=applicat ion; appids="myapplicationl" 

Event : ua-prof ile;profile-type=application; 

appids="myapplication2 ,myapplication3 " 
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The table shows the use of Event header parameters in SUBSCRIBE requests for the apphcation profile type: 



profile -type | | 


application 


appids 1 1 


s 


vendor | | 


o 


model 1 1 


o 


version | | 


o 


effective-by | | 





m - mandatory 

s - SHOULD be provided 

o - optional 



The table shows the use of Event header parameters in NOTIFY requests for the apphcation profile type: 



profile-type | | application 



appids 1 1 


s 


vendor | | 




model 1 1 




version | | 




effective-by | | 


o 



Y.3.4 SUBSCRIBE Bodies 

The present document defines an enhancement to the I-D.ietf-sipping-config-framework [63] by specifying a use for the 
SUBSCRIBE request body. If the appids parameter contains a single application identifier, the SUBSCRIBE message 
body MAY contain a single body part appropriate for the application. If the appids parameter contains a list of 
applications, the body of the SUBSCRIBE MAY contain a "multipart/mixed" content-type, with appropriate body parts 
for each of the apphcations for which the UA is subscribing. 

The body parts MUST be in the same order in which they are listed in the "appids" parameter, and if any body parts are 
present, all applications must have a corresponding part, even if empty. 

If present in the SUBSCRIBE request, the body SHALL be used by the apphcation-specific PDS to tailor the NOTIFY 
responses to the subscribing UA for each of the applications listed. The meaning and form of the SUBSCRIBE body is 
specified by each application. 

NOTE: An alternative to requiring all applications to have body parts if any do, and to using "empty" parts where 
a body part is not needed, is to employ Content-Description to name the appid to which the part 
corresponds. 

Y.3.5 NOTIFY Bodies 

The NOTIFY message body contains a content type specific to the requested apphcation (this type must be hsted in the 
Accept header of the SUBSCRIBE). If the subscription is for multiple applications, the initial NOTIFY message body 
will contain a "multipart/mixed" content-type, and the ordering of the body-parts corresponds to the ordering of the 
"appids" application values. 



Y.4 Example Usage 

SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 
©example. com SIP/2.0 
Event : ua-prof ile; profile -type=applicat ion; appids="sampleapplicat ion" 
From: sip:um%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 

©example . com; tag=1234 
To: sip :urn%3auuid%3a00000000- 0000 -1000 -0000 -00FF8D82EDCB@example.com 
Call -ID: 3573853342 9234220192 .0.2 .44 
CSeq: 2131 SUBSCRIBE 

Contact : sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB 
©example . com 

; +sip . instance="<urn:uuid: 00000000 -0000 -0000 -0000- 123456789AB0>" 
Via: SIP/2. 0/TCP 192.0.2.41; 

branch=z9hG4bK6d6d35b6e2a2 03104d97211a3dl8f 57a 
Accept : message/external-body, application/x-zlOO-device-prof ile 
Content -Length: 
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Annex Z (normative): 

SDP attributes for IMS-based IPTV 

Z.O General 

RFC 2327 [68] generically defines SDP attributes as follows: 

attribute- fields = *("a=" attribute CRLF) 

attribute = (att-field ":" att-value) | att-field 

This annex specifies several IPTV attributes as special cases of this ABNF syntax. 

Z.1 SDP attributes for Personalized Service Composition 
Z.1 .1 SDP attribute for PSC identifier 

The SDP attribute a=PSCid is used to signal that a particular SIP session is part of a PSC. The use of this attribute is 
specified in clauses 5.1.11 and 5.3.10. The Augmented Backus-Naur Form [61] specification of this SDP attribute is as 
follows: 

psc-attribute- field = "a=" psc-attribute CRLF 
psc-attribute = "PSCid" ":" PSCid 

PSCid = *(%x21-7E); Zero or more of any printable character, except for "space". 

The following is an example of the SDP attribute for PSC identifier: 

• a=PSCid:MyPersonalisedServiceCompositel2345<>[[[-+! @#$%^&*() 

NOTE: As specified in ABNF above, the attribute parameter of a=PSCid is case-sensitive. So "a=PSCid:case" is 
different from "a=PSCid:CASE". 

Z.2 SDP attributes for BC 
Z.2.1 SDP attributes for BC Service 

The SDP attribute a=bc_service is used to signal the BCServiceld (channel).The use of this attribute is specified in 
clauses 5.1.3 and 5.3.1. The Augmented Backus-Naur Form [61] specification of this SDP attribute is as follows: 

bc-service-attribute-f ield = "a=" bc-service-attribute CRLF 
bc-service-attribute = "bc_service" ":" BCServiceld 

BCServiceld = *16(ALPHA / DIGIT / "-"); Zero up to 16 letters, digits or dashes. 

The following is an example of the SDP attribute for BC service identifier. 

• a=bc_service:CCTV-5-Sports 

Z.2.2 SDP attributes for BC Service Package 

The format of the a=bc_service_package attribute shall be the following: 

bc-service-package-attribute-f ield = "a=" bc-service-package-attribute CRLF 
bc-service-package-attribute = "bc_service_package" ":" BCPackage 
BCPackage = BCPackageld mult-list "] " ) ; or 1 mult_list 
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BCPackageld = *16 (ALPHA / DIGIT / "-"); Zero up to 16 letters, digits or dashes. 

mult-list = "mult_list:" source-unit *("/" source-unit) ; 1 or more source-unit 

source-unit = " [" 0*1 ( "src_list : " source-addresses) "] " multicast-addresses " [" BCServiceld "] " 

; one BCService Id, one or more multicast addresses, and optionally one or more source addresses 
source-addresses = IPaddresses ; source addresses should be unicast IP addresses 
multicast-addresses = IPaddresses ; these should be multicast IP addresses 
IPaddresses = (IPaddress / IPaddress-range) *("," (IPaddress / IPaddress-range) ) 
IPaddress-range = IPaddress "-" IPaddress ; lowest and highest value of the IP address range 
IPaddress = IPv4address / IPvSaddress 



BCServiceld is defined in clause Z.2.1 (ABNF notation). 

BCPackageld is the service package ID string. 

IPv4 address and IPv6 address are specified in RFC 3261 [62], clause 25. 

NOTE: An essential correction to the ABNF of IPv6address is proposed in [1 1]. Implementers are advised to 
follow that guideline. 

The following are examples of the SDP attribute for BC service package: 

a=bc_service_package : P25-News-Sports 

a=bc_service_package : P25-News-Sports [mult_list : [] 225 .10.3.0 [CCTV- 5 -Sports] ] 
a=bc_service_package : P25-News-Sports [mult_list : [src_list : 192 . 168 . 10 . 1] 225 . 10 . 3 . 
a=bc_service_package : P25-News-Sports [mult_list : [src_list : 192 . 168 . 10 .1-192 . 168 . 10 
225. 10.4. 255, FF02: :2-FF02: :8 [CCTV- 5- 

Sports] / [src_list :192. 168. 11. 1,2001: cdba : :3257:9652]FF02: :10 [CCTV- 9- 
News] / [src_list : 192 . 168 . 11 .2] FF02 : : 13 [CCTV- 8 -News] / [] FF02 : : 14 [CCTV- 6 -Sports] ] 

As seen in this notation the multi_list parameter can contain one or more source_unit parameters with multicast 
addresses that can be separated with either "," or When they are separated with "-" it means that it is a range of 
addresses. In addition there can optionally be a list of source addresses within the source unit parameter which is 
appUcable for all the multicast addresses within the source unit parameter. 

Z.2.3 SDP attributes for BC Program 

The SDP attribute a=bc_program is used to signal the BC program ID. The use of this attribute is specified in 
clauses 5.1.3 and 5.3.1. The Augmented Backus-Naur Form [61] specification of this SDP attribute is as follows: 

bc-program- field = "a=" bc-program-attribute CRLF 
bc-program-attribute = "bc_program" " : " BCprogramId 

BCprogramId = *16 {ALPHA / DIGIT / " - " ) ; Zero up to 16 letters, digits or dashes. 

The following is an example of the SDP attribute for BC program identifier. 
• a=bc_program:USA-Movie-Superman 



[CCTV- 5 -Sports] ] 
.255]225.10.3.0- 
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Annex ZA (normative): 
Definition of Info Pacl<ages 

This annex defines the Info packages required in support of IPTV 



ZA.1 Playlist Info Package 

The Playlist Info Package is used to send a list of network-owned content to any application that requires it using SIP 
INFO requests. The content is transparent to the end user in the sense that the user cannot perform any trick-mode 
operations on any content in the playlist 

ZA.1.1 Overall General 

This clause contains the information required for the lANA registration of an Info Package. 

ZA.1. 2 Overall Description 

Playlist are normally sent by a network-owned control server to a streaming server during an established session with 
the streaming server. The playlist includes a list of content allowing the streaming server to stream the content to an 
end-user according to the indicated time per content. The PlayUst Info Package is used to transport the necessary 
information regarding the content to be streamed to the end-user. 

The Playlist Info Package is used to transfer a single list at any time. As such, only one list is transported in a single SIP 
INFO request. The list can include multiple contents. 

The Playlist Info Package is defined for any multimedia appUcation that incorporates content streaming. Any 
appUcation, where sending a playlist using the SIP ESTFO method is required, can use the Playlist Info Package. 

ZA.1. 3 Applicability 

The Info Package mechanism for transporting a list of content has been chosen since this is a service that some 
networks may offer, and as such it is optional. The mechanism also allows the list of content to be sent inside an 
existing dialog, using the same signalling path as other SIP messages within the dialog, rather than having to establish a 
separate dialog. This is especially important since the playlist is only pertinent to the sessioZA. 

ZA.1. 4 Info Package Name 

The name of the content bookmark Info Package is: Playlist 

ZA.1. 5 Info Package Parameters 

No parameters are defined for the Playlist Info Package. 

ZA.1. 6 SIP Option Tags 

No SIP option tags are defined for the Playlist Info Package. 
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ZA.1.7 INFO Message Body Parts 
ZA. 1.7.1 General 

The playlist sent as part of the message body of the SIP INFO request. This clause defines the information and syntax 
associated with the message body part used for transporting the play hst. 

ZA.1 .7.2 SIP Content-Type header field value 

The value of the SIP Content-Type header field associated with the Playlist Info Package message body is: 
appUcation/vnd.etsi.playlist+xml. 

ZA.1 .7.3 SIP Content-Disposition header field value 

The value of the SIP Content-Disposition header field associated with the PlayUst Info Package message body is: Info- 
Package. 

ZA.1 .7.4 Message body syntax 

The syntax of the Playhst Info Package message body is based on the rules defined in clause 5.3.9.1. 

ZA.1. 8 Info Package Usage Restrictions 

No usage restrictions are defined for the Playlist Info Package. 

ZA.1 .9 Rate of INFO Requests 

No maximum rate or minimum rate is defined for sending INFO requests associated with the Playlist Info Package. 

When Playlist requests are generated, the package does not provide a feedback mechanism to indicate to the sender that 
the rate of Playlist generation is too slow or fast. However applications in the network can control the rate of generation 
from users if they so desire. 

ZA.1. 10 Info Package Security Considerations 

No additional security mechanism is defined for the Playlist Info Package. 

The security of the Playlist Info Package is based on the generic security mechanism provided for the underlying SIP 
signalling. 

ZA.1 .1 1 1mplementation Details and Examples 

Examples of the Playlist Info Package usage can be found in clause 5.3.9. 



ZA.2 Restricted-Trickplay-Policies Info Package 

The Restricted-Trickplay-Policies Info Package is used to send to a streaming server or an end-user streaming 
application a list of policies regarding trickplay restrictions on a streamed content that a user cannot perform using SIP 
INFO requests 

ZA.2.1 Overall General 

This clause contains the information required for the lANA registration of an Info Package. 
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ZA.2.2 Overall Description 

Restricted-Trickplay-Policies Playlist is normally sent by a control server to a streaming server or an end-user streaming 
application during an established session with the streaming server. This allows the server to enforce polices in regard 
trick plays that could not be performed over some segment of the content while the content is being streamed. This is 
useful if certain content segments such as ads should not be skipped as an example. The Restricted-Trickplay-Policies 
Info Package is used to transport the necessary information regarding those policies. 

The Restricted-Trickplay-Policies Info Package is used to transfer a single list at any time. As such, only one list is 
transported in a single SIP INFO request. The list can include multiple policies. 

The Restricted-Trickplay-Policies Info Package is defined for any multimedia application that incorporates content 
streaming and that wishes to impose restrictions on trickplays while streaming the content. Any application, where 
sending restricted trickplay policies using the SIP INFO method is required, can use the Restricted-Trickplay-Policies 
Info Package. 

ZA.2.3 Applicability 

The Info Package mechanism for transporting a list of Restricted trickplay policies has been chosen since this is a 
service that some networks may offer, and as such it is optional. The mechanism also allows the list of policies to be 
sent inside an existing dialog, using the same signalling path as other SIP messages within the dialog, rather than having 
to establish a separate dialog. This is especially important since the policies are only pertinent to the session and the 
content streamed thereiZA. 

ZA.2.4 Info Package Name 

The name of the Info Package is: Restricted-Trickplay-Policies. 

ZA.2.5 Info Package Parameters 

No parameters are defined for the Restricted-Trickplay-Policies Info Package. 

ZA.2.6 SIP Option Tags 

No SIP option tags are defined for the Restricted-Trickplay-Policies Info Package. 

ZA.2.7 INFO Message Body Parts 
ZA. 1.7.1 General 

The trickplay restricted policies are sent as part of the message body of the SIP INFO request. This clause defines the 
information and syntax associated with the message body part used for transporting the policies. 

ZA.2.7.2 SIP Content-Type header field value 

The value of the SIP Content-Type header field associated with the Restricted-Trickplay-Policies Info Package message 
body is: "application/vnd.etsi.iptvrestrictedtrickplay+xml" 

ZA.2.7.3 SIP Content-Disposition header field value 

The value of the SIP Content-Disposition header field associated with the Restricted-Trickplay-Policies Info Package 
message body is: Info-Package. 
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Zk.21A Message body syntax 

The syntax of the Restricted-Trickplay-Policies Info Package message body is based on the rules defined in 
clause 5.3.7. 

ZA.2.8 Info Package Usage Restrictions 

No usage restrictions are defined for the Restricted-Trickplay-Pohcies Info Package. 

ZA.2.9 Rate of INFO Requests 

No maximum rate or minimum rate is defined for sending INFO requests associated with the Restricted-Trickplay- 
Pohcies Info Package. 

ZA.2.10lnfo Package Security Considerations 

No additional security mechanism is defined for the Restricted-Trickplay-Policies Info Package. 

The security of the Restricted-Trickplay-Policies Info Package is based on the generic security mechanism provided for 
the underlying SIP signalling. 

ZA.2.1 1 1mplementation Details and Examples 

Examples of the Restricted-Trickplay-Policies Info Package usage can be found in clauses 5.3.7 and 5.4.6. 



ZA.3 IPTV-Content-Marker Info Package 

The IPTV-Content-Marker Info Package is used to send a content bookmark to any application that requires it using 
SIP INFO requests 

ZA.3.1 Overall General 

This clause contains the information required for the lANA registration of an Info Package. 

ZA.3. 2 Overall Description 

IPTV Content Markers are normally sent by a user while watching content when a user desires to store information 
regarding a position in time in the streamed content that he wants to locate later when viewing the same content. The 
bookmarked position allows the user to start viewing from the bookmarked positioZA. The IPTV-Content-Marker Info 
Package is used to transport the necessary information regarding that point in time for storage in the network. 
Information regarding the stored content bookmark can be later retrieved by the user. 

The IPTV-Content-Marker Info Package is used to transfer a single content bookmark at any time. As such, only one 
content bookmark is transported in a single SIP INFO request, 

The IPTV-Content-Marker Info Package is defined for any multimedia application that incorporates content streaming. 
Any application, where sending content bookmark information using the SIP INFO method is required, can use the 
IPTV-Content-Marker Info Package. 
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ZA.3.3 Applicability 

The Info Package mechanism for transporting content bookmarks has been chosen since this is a service that some 
networks may offer, and as such it is optional. Also networks that offer the service may impose a limit on the number of 
content bookmarks per subscriber to be stored in the network. As such, the network would restrict users who have 
exceeded their quota from sending any more bookmarks to it. Finally, the mechanism also allows content bookmarks to 
be sent inside an existing dialog, using the same signalling path as other SIP messages within the dialog, rather than 
having to establish a separate dialog. 

ZA.3.4 Info Package Name 

The name of the content bookmark Info Package is: IPTV-Content-Marker 

ZA.3.5 Info Package Parameters 

No parameters are defined for the IPTV-Content-Marker Info Package. 

ZA.3.6 SIP Option Tags 

No SIP option tags are defined for the IPTV-Content-Marker Info Package. 

ZA.3.7 INFO Message Body Parts 
ZA.3.7.1 General 

The Content bookmarks are sent as part of the message body of the SIP INFO request. This clause defines the 
information and syntax associated with the message body part used for transporting the content bookmarks. 

ZA.3.7.2 SIP Content-Type header field value 

The value of the SIP Content-Type header field associated with the IPTV-Content-Marker Info Package message body 
is: "application/vnd.etsi.iptvcontentmarker+xml" 

ZA.3.7.3 SIP Content-Disposition header field value 

The value of the SIP Content-Disposition header field associated with the IPTV-Content-Marker Info Package message 
body is: Info-Package. 

ZA.3.7.4 Message body syntax 

The syntax of the IPTV-Content-Marker Info Package message body is based on the rules defined in clause 5.1.14 and 
5.3.13. 

ZA.3.8 Info Package Usage Restrictions 

No usage restrictions are defined for the IPTV-Content-Marker Info Package. 

ZA.3.9 Rate of INFO Requests 

No maximum rate or minimum rate is defined for sending INFO requests associated with the IPTV-Content-Marker 
Info Package. 
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When IPTV-Content-Marker requests are generated by users, the package does not provide a feedback mechanism to 
indicate to the sender that the rate of IPTV-Content-Marker generation is too slow or fast. However apphcations in the 
network can control the rate of generation from users if they so desire. 

ZA.3.10lnfo Package Security Considerations 

No additional security mechanism is defined for the IPTV-Content-Marker Info Package. 

The security of the IPTV-Content-Marker Info Package is based on the generic security mechanism provided for the 
underlying SIP signalling. 

ZA.3.11 Implementation Details and Examples 

Examples of the IPTV-Content-Marker Info Package usage can be found in clause 5.1.14. 



ZA.4 Event-Notification Info Package 

The Event-Notification Info Package is used to send to an application unsolicited application events that the 
apphcations is required to act on using SIP INFO requests. 

ZA.4.1 Overall General 

This clause contains the information required for the lANA registration of an Info Package. 

ZA.4.2 Overall Description 

Notifications about events are normally sent when an action is required by an application such as inserting an ad to a 
user who has paused a streamed content. In these cases, the reason for the event is signalled in the event itself so the 
appUcation knows what it needs to do. 

The Event-Notification Info Package is used to transfer a single event at any time. As such, only one event is 
transported in a single SIP INFO request. 

The Event-Notification Info Package is defined for any multimedia application that incorporates content streaming. Any 
appUcation, where sending events using the SIP INFO method is required, can use the Event-Notification Info Package. 

ZA.4.3 Applicability 

The Info Package mechanism for transporting application events has been chosen since this is a service that not all 
applications may support, and as such it is optional. Finally, the mechanism also allows application events to be sent 
inside an existing dialog, using the same signalling path as other SIP messages within the dialog, rather than having to 
establish a separate dialog. 

ZA.4.4 Info Package Name 

The name of the event notification Info Package is: Event-Notification. 

ZA.4.5 Info Package Parameters 

No parameters are defined for the Event-Notification Info Package. 
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ZA.4.6 SIP Option Tags 

No SIP option tags are defined for the Event-Notification Info Package. 
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ZA.4.7 INFO Message Body Parts 
ZA.4.7.1 General 

Notification events are sent as part of the message body of the SIP INFO request. This clause defines the information 
and syntax associated with the message body part used for transporting the notification events. 

ZA.4.7.2 SIP Content-Type header field value 

The value of the SIP Content-Type header field associated with the Event-Notification Info Package message body is: 
" application/vnd.etsi.iptvnotification+xml ". 

ZA.4.7.3 SIP Content-Disposition header field value 

The value of the SIP Content-Disposition header field associated with the Event-Notification Info Package message 
body is: Info-Package. 

ZA.4.7. 4 Message body syntax 

The syntax of the Event-Notification Info Package message body is based on the rules defined in clause 5.1.13. 

ZA.4.8 Info Package Usage Restrictions 

No usage restrictions are defined for the Event-Notification Info Package. 

ZA.4.9 Rate of INFO Requests 

No maximum rate or minimum rate is defined for sending INFO requests associated with the Event-Notification Info 
Package. Given that these events are typically generated by network servers, the network can control the rate itself. 

ZA.4.10lnfo Package Security Considerations 

No additional security mechanism is defined for the Event-Notification Info Package. 

The security of the Event-Notification Info Package is based on the generic security mechanism provided for the 
underlying SIP signalling. 

ZA.4.1 1 1nnplennentation Details and Exannples 

Examples of the Event-Notification Info Package usage can be found in clause 5.1.13. 



ZA.5 GoD-Playlist Info Package 

The CoD-Playlist Info Package is used to send to a streaming server a list of content held by the server using SIP INFO 
requests. This allows the server to sequentially stream the list of content to an end user. 
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ZA.5.1 Overall General 

This clause contains the information required for the lANA registration of an Info Package. 

ZA.5.2 Overall Description 

Cod-Playlist is normally sent by a user to a streaming server once a session is established with the server. The CoD 
playUst includes a Ust of content allowing the streaming server to stream the content to an end-user sequentially. The 
user can equally switch streaming between the different contents in the playUst. CoD play lists are typically created and 

updated by the end-user. 

The CoD-Playhst Info Package is used to transfer a single list at any time. As such, only one hst is transported in a 
single SIP INFO request. The list can include multiple contents. 

The CoD-Playlist Info Package is defined for any multimedia appUcation that incorporates content streaming. Any 
appUcation, where sending a playUst using the SIP INFO method is required, can use the Playlist Info Package. 

ZA.5.3 Applicability 

The Info Package mechanism for transporting the CoD list of content has been chosen since this is a service that some 
networks may offer, and as such it is optional. The mechanism also allows the list of content to be sent inside an 
existing dialog, using the same signalling path as other SIP messages within the dialog, rather than having to establish a 
separate dialog. This is especially important since the playlist is only pertinent to the session ZA. 

ZA.5.4 Info Package Name 

The name of the content bookmark Info Package is: CoD-Playlist. 

ZA.5.5 Info Package Parameters 

No parameters are defined for the CoD-Playhst Info Package. 

ZA.5.6 SIP Option Tags 

No SIP option tags are defined for the CoD-Playlist Info Package. 

ZA.5.7 INFO IVIessage Body Parts 
ZA.5.7.1 General 

The CoD playlist is sent as part of the message body of the SIP INFO request. This clause defines the information and 
syntax associated with the message body part used for transporting the CoD-Playlist. 

ZA.5.7.2 SIP Content-Type header field value 

The value of the SIP Content-Type header field associated with the CoD-Playlist Info Package message body is: 
"apphcation/vnd.etsi.iptvcontentswitch-Hxml". 

ZA.5.7.3 SIP Content-Disposition header field value 

The value of the SIP Content-Disposition header field associated with the CoD-Playlist Info Package message body is: 
Info-Package. 
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ZA.5.7.4 Message body syntax 

The syntax of the CoD-Playlist Info Package message body is based on the rules defined in clause 5.3.15.2. 

ZA.5.8 Info Package Usage Restrictions 

No usage restrictions are defined for the CoD-Playlist Info Package. 

ZA.5.9 Rate of INFO Requests 

No maximum rate or minimum rate is defined for sending INFO requests associated with the CoD-Playlist Info 
Package. 

ZA.5.10lnfo Package Security Considerations 

No additional security mechanism is defined for the CoD-Playlist Info Package. 

The secmty of the CoD-Playlist Info Package is based on the generic security mechanism provided for the underlying 
SIP signalling. 

ZA.5.1 1 1mplementation Details and Examples 

Examples of the CoD-Playhst Info Package usage can be found in clause 5.3.9. 
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